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.