Meredith Bailey of StreamWork On The 5 Habits That Can Accelerate Product Development Cycles

All new products start with an idea and then continue through the stages of development. What are the 5 habits that can accelerate product development cycles? In this interview series, we are talking to product managers, founders, and thought leaders who can share stories and insights from their experiences about how to accelerate product development cycles. As part of this series, we had the distinct pleasure of interviewing Meredith Bailey, Founder & CEO of StreamWork

Meredith worked in product marketing at Apple, Google, YouTube, and Warner Bros. developing and launching several of the world’s most beloved technology products. During her career, she worked on dozens of campaigns and hundreds of creative assets with cross-functional teams. She felt the pain points firsthand when it came to collecting rounds of feedback and stakeholder approvals on creative and built StreamWork (www.streamwork.com) — the first review, approval, and project management platform for creative assets — to fix it.

‍

‍

Thank you so much for joining us in this interview series! Before diving in, our readers would love to learn more about you. Can you tell us a story about what brought you to this specific career path?

I built StreamWork based on my personal experience working on hundreds of creative assets across marketing teams at Apple, Google, YouTube, and Warner Bros. Having launched and scaled dozens of technology products, it became clear to me that one of the biggest pain points in shipping creative was managing stakeholder feedback. Whether we were launching a brand refresh or a new feature, every campaign required videos, images, logos, one-pagers, sales decks and more. With each piece of collateral developed, the number of cross-functional stakeholders weighing-in would multiply, making it harder to launch creative on time, according to spec, and in line with the original brief.

‍

I created StreamWork — the first review, approval and project management platform built for creative assets — to fix this problem. When you work in a creative role, the challenge of reviewing creative is constant and demanding. While StreamWork was built for marketers and agencies, we are increasingly seeing teams of all types use the platform because the pain of needing to gather feedback quickly and succinctly across multiple stakeholders and departments, is a near universal problem. StreamWork is very personal to me as it’s the product that I wish I had in all my past roles — it would have saved me a tremendous amount of time and energy. My focus is to ensure teams reviewing any type of creative asset today don’t need to face the same complications I felt, so they can spend less time on the process and more time developing creative.

Do you have any mentors or experiences that have particularly influenced your approach to product development and user experience?

Yes. I’ve been fortunate to work with some of the sharpest product marketers out there in my past roles. I joined Apple early in my career, so a lot of my understanding of how to develop, position and sell products was formulated while I was there. I worked with several fantastic marketing leaders on the product marketing team at Apple, including one my mentors: Michael Newey. Michael taught me the importance of simplicity and helped me grasp the power of storytelling in go-to-market.

‍

I also had the opportunity to work with many of the brightest product managers and engineers at Google, including Max Goldman. I worked on the launch of a suite of video creation products at YouTube alongside Max and his team. Max and his team were scrappy, hard-working, and out-of-the-box thinkers, and kindly brought me into their fold. I loved their intense focus on the end user. They were resolved on delivering products and services that made the lives of their users better, and every decision reflected how to develop something not only for the customer, but in service of the customer.

‍

‍

It has been said that our mistakes can sometimes be our greatest teachers. Can you share a story about the funniest mistake you made when you were first starting? Can you tell us what lesson you learned from that?

Early on as a Product Marketing Manager at Google, I worked on an experimental product with a team of engineers and designers. I was tasked with positioning the product for go-to-market. I worked closely with cross-functional stakeholders to align on the final product positioning and receive sign-off. However, as stakeholder approvals were flowing in, so too was additional user feedback. It became clear that our positioning was not resonating with users in the way we had intended. We ran more user testing, scrapped nearly six months of work, and started fresh.

‍

The experience cemented in me how critical user testing is to the product development process — and the need to test early and often. We were fortunate that testing caught our positioning mistake before we launched, because once we did launch, it wasn’t a guess whether we would resonate with users. We were confident the product would land as intended. Certainly not funny at the time, but looking back on this, I do chuckle sometimes as it was a lesson hard earned, and one that I’ve made sure not to repeat!

‍

‍

What do you feel has been your ‘career-defining’ moment? We’d love to hear the lead-up, what happened, and the impact it had on your life.

My hope is that my ‘career-defining’ moment has not yet happened, but if I were to choose one moment to date, I would choose the moment we received the first feedback from early customers on StreamWork. They used words like “game-changing product” and “saved countless hours.” These are the type of reviews I would have previously expected to hear for a mature product, not necessarily for a new product. To hear reviews like these at such an early stage was a major inspiration and driving force for our team. We knew that not only had we built a product with product-market fit, but we had built something that was going to add value to our customer’s lives. When you’re building a product to address a specific pain point and end user, there is no greater accolade.

‍

‍

Can you tell us a story about the hard times that you faced when you first started your journey? Did you ever consider giving up? Where did you get the drive to continue even though things were so hard?

Before StreamWork, I had never built a product from scratch before. I had extensive experience working with product, engineering, sales, and design teams to launch products, but this was my first time turning an idea into a reality. What was apparent to me from the start is I needed to find a team that filled my gaps in experience and knowledge. I am not a trained software engineer, nor do I have a Computer Science degree, so my first step was to talk to as many engineers and technical product leaders I could find to pick their brains. I learned you truly don’t know what you don’t know — and talking to as many people as possible (even via cold outreach) is a good way to avoid mistakes before you inadvertently make them!

‍

‍

How do you stay on top of market trends and developments in the product management space?

I read several publications daily including Medium. I find that the personal experiences shared by Product Managers in these types of publications offer insightful and hands-on solutions for how to approach product development — and what pitfalls to avoid. I also love talking with product managers, founders and engineers, no matter what industry they work in. Whenever I have the chance to join a founder’s dinner or attend a startup event, I jump at the opportunity. I’ve met incredible people at these events and always walk away with a fresh perspective I hadn’t considered before.

‍

‍

What role does cross-functional collaboration play in accelerating product development cycles, and how do you foster effective collaboration across different teams and departments?

I’m happy you asked this, because from my perspective, effective cross-functional collaboration is one of the most important avenues for accelerating product development cycles. I was a Product Marketing Manager before I became a Founder, so my approach to product development is strongly influenced by my background. Product marketing is highly cross-functional in nature. When you are preparing a product to go-to-market, you are working closely with all departments to ensure you’re getting product, positioning, promotion, and packaging right.

‍

This same learning applies to product development. The more you involve the right cross-functional stakeholders at the right time, the quicker you’ll be able to identify bottlenecks and align on solutions. Fostering effective collaboration is not easy (it’s the reason we built StreamWork), but a framework we’ve found to be useful is the DACI, which stands for Driver, Approver, Contributor and Informed. At the start of a project, you assign cross-functional stakeholders to the role where they can add most value — ex. You are likely the product driver, you may have final approvers weigh-in from Product and Engineering leadership, and then sales and customer success are most likely consulted or informed throughout. We are such big fans of this framework that we automated it and built it into StreamWork, so teams no longer need to run approvals on creative assets manually.

‍

‍

Thank you for all of that. Here is the main question of our interview. Based on your experience, what are your “The 5 Habits That Can Accelerate Product Development Cycles”? If you can, please share a story or an example for each.

1. Hire a solution-oriented team: When I started StreamWork, it became clear that the most important aspect of the business would be the team. It’s imperative to hire team members who share your vision, understand the tasks at hand, and who will be solution-oriented when it comes to providing opinions to make the product stronger. When I set out to hire a team, I started by interviewing designers and software engineers. What I learned is: 1) Ask subject matter experts in your network to help you interview to see if someone’s skills are where they need to be, 2) Get an understanding for whether someone is solution oriented. For example, if they are tasked with a problem, do they give up, or do they start brainstorming alternative solutions? I found this to be a critical trait that has helped us overcome countless bumps that we’ve encountered in our product build.

‍

2. Involve engineers from the beginning: When you set out to build a software product, you usually start by defining the specs, then you hire designers to wireframe the concept, test the prototypes, and eventually bring the UI to life. After that point, you kick-off development of the build. It can be tempting to only work with UX/UI designers at the start given you’re primarily mapping out the wireframes, however, do not make this mistake. It is imperative to involve a technical lead in every wireframe discussion, not as a consultant but as a core decision-maker. Some technical leads may want to maintain an arm’s length distance from wireframe development as it’s not their purview, but my recommendation is to set-up your team for success by including a lead engineer in daily wireframe conversations from the start.

‍

3. Draft specifications before your build: There is a lot of focus on building and iterating in the start-up world, and I agree this is a smart approach. However, if you dive into building something without a strategy or clear specs in place first, you risk duplicative work and lost time. When I set out to build StreamWork, I drafted extensive specs and used simple prototyping tools like Balsamiq to create “napkin” drawings of what I was looking to build. Mapping out a plan in advance of hiring a team ended up being the best decision I could have made. It meant that the team I onboarded immediately understood what we were building and could align around the product vision. It also meant that each designer and engineer we onboarded would be tasked with reading the specs as their first assignment and would in turn be encouraged to provide ideas and feedback to improve the product. The specs were a lever for product brainstorming and iteration.

‍

4. Test, test, and test some more: The golden rule of product marketing is that the user comes first. When I set out to build StreamWork, I knew that no matter the domain experience I brought to the table, ultimately, the only thing that mattered was whether our customers found value in StreamWork. The best way to figure this out? Test the product obsessively and get it in the hands of real users. We tested StreamWork at every stage of our build: initial wireframes, early prototypes, and final product. We also tested various flows and features within or around the product, including onboarding, pricing, landing pages and more. The reason you test is to listen and learn. If you take the necessary time to apply the feedback, it will ultimately pay back in spades, while saving your team precious development time in the long run.

‍

5. Tackle the difficult tasks first: As painful as it is to tackle the most time-consuming and mentally demanding tasks first, force yourself to do it. When it comes to software development, there are several daunting workstreams early on that you’ll naturally want to avoid. Challenge your team to not put these workstreams to the side. Tackle them early and head on, then allow your team to iterate overtime as you discover new information. Mapping out roles and access permissions for StreamWork was one of the hairiest aspects of our build because we set out to create a secure, enterprise-ready solution from the start. While it’s imperative to understand fundamentals like roles early on, our team forced ourselves to go the extra mile and map out every detail.

What are some of the common pitfalls that you see product teams fall into when trying to accelerate their development cycles, and how can these be avoided?

I often see cumbersome processes, like feature prioritization and bug management, become a pitfall for product teams. One of the advantages of a startup is you can execute faster. Smaller teams tend to be more aware of the broader product vision and strategy, and less burdened by process. I’m a big fan of effective processes, so I’m not advising there be no process in place. Instead, as teams and companies grow, it’s important for product leaders to be aware of the processes being implemented across their team (both within their department and cross-functionally) to ensure the processes are consistent, up to date, and actively adding value.

‍

‍

Can you share an example of a time when you had to make a tough tradeoff between speed and quality during a product development cycle, and what was the outcome of that decision?

One of our team’s core principles is that we will not sacrifice quality on anything we ship. We have a process in place where every feature we develop must undergo several internal checks, including QA testing, before we push live to production. This process has enabled us to ship quality features quickly, while also ensuring we catch any bugs prior to release. We’ve also adopted a phased approach to launching StreamWork so we can quickly iterate. For instance, our initial MVP included the core workflows of the product but did not include all features on our roadmap. This was intentional because we wanted to push a quality MVP to our design partners quickly so that we could start collecting their real-life feedback on the platform as well as hear about what features they needed most. This helped us prioritize our roadmap and subsequently release features on a rolling basis that we knew would drive value for our customers.

‍

‍

How important is a data-driven approach to product development, and can you share a story where data significantly influenced your decision-making process?

It’s extremely important. We are constantly monitoring all aspects of StreamWork from back-end performance to usage metrics. We use Mixpanel to better understand what features drive value for our customers, which has helped to inform not only strategy, prioritization, and development, but also customer conversations. Whenever our team runs into a disagreement about a product or feature, we typically turn to data to reach a resolution. This is a practice I picked up at Google where data is paramount. If you do not know the answer to a question, seek data to better understand your users and find a solution.

‍

‍

Can you share an instance where user feedback led to a significant pivot in your product development strategy?

When it comes to StreamWork, user feedback has shaped every workflow and feature in the product. We’ve made countless updates to our build based on feedback. Most recently, we received user feedback that users were looking for an easier way to onboard into StreamWork, without the need for a demo. We took this feedback to heart and built an entirely new self-serve onboarding module for any user who would prefer to discover the product in their own way, and on their own time. This is a significant pivot from how users originally onboarded into StreamWork, and we’re excited to continue to collect feedback as more and more users try it out.

‍

‍

We are very blessed that very prominent leaders read this column. Is there a person in the world or in the US with whom you would love to have a private breakfast or lunch, and why? He or she might just see this if we tag them :-)

Sara Blakely. I’m in awe of not only the company and culture she built, but also how she built it. I recently read that in the early days of building Spanx, a buyer she was pitching to was losing interest in a meeting, so Sara asked the buyer to try on Spanx right then and there! I love the ingenuity of the sale, and the focus and grit it must have taken to build Spanx into what it is today.

‍

‍

Thank you so much for this. This was very inspirational, and we wish you only continued success!

Thank you for the opportunity to participate!

‍

. . .

Originally published at https://medium.com/authority-magazine.