product, simplified.
Want a regular behind-the-scenes look at the tactics, routines, and habits of world-class product teams?
.png)
Hi, I'm Cambria, a Product Manager at Ro.
The common wisdom around launching a product is simple. You research a problem, define an MVP, get to your first user, and iterate until you hit product/market fit. Sounds easy, right?
I had 6 months to launch a brand new product for a +$1B company. As a new PM, no less. It turned out well, in the end. A year later, we had over $11.6M ARR and over 57,000 survey submissions from customers (it was a survey tool).
But, it was hard.
I built this resource to help other product teams launch better products. This resource covers a series of actionable frameworks and the potholes and principles that will get you from nothing to something — from actually defining an MVP, to getting your first user, and iterating to launch.
Resources
Customer Interviews
This is the interview script and summary slide deck I used to distill learnings to our team.
1
Know your customers, and their problems.
We started by scheduling interviews with our target customers. We asked them four core questions:
1. What do they want?
2. What are their problems?
3. What are they currently doing to solve those problems?
4. How do they imagine their life improving with a better solution?
Couple this qualitative research with research into the industry and competitive landscape.
Then, we ran a workshop to unpack and distill learnings to the whole team. With those learnings, we could start brainstorming solutions too.
Setting Product Principles
This is an outline of the workshop we used to define our product principles. More great reading on this below.
2
Prioritize problems & potential solutions.
We then set principles, driven by the problems we identified. These principles enabled us to develop maniacal focus on nailing a few core attributes, while helping us say no to everything else.
Once we had a solid understanding of our customers’ problems and some great ideas on how to solve them, we mapped them out on a problem matrix to prioritize what we should solve for based on the impact and ease of implementation (from a development, research, and design standpoint).
Defining an MVP
This is an outline of the Intercom's cupcake framework we used to define our MVP. More great reading on this below.
3
Define your MVP & milestones.
Once we defined what the “ideal” looks like, we worked backwards. Note: be RUTHLESS about the MVP you define. It’s always easier to add features than subtract them later. To me, our MVP seemed sparse at the time, but we could’ve scoped it down much further.
Write down your core assumptions and test the features that you’re considering developing against those assumptions.
Once you have a clear MVP, define milestones for your team to get there.
Communicate the Vision
Compile your research, the solution that you and your team have come up with, the principles that you’ve set, and break all of those goals down into detailed milestones that clearly convey how you’re going to achieve that vision. Here are some of my favorite examples:
AirBnB pitch deck
Mixpanel pitch deck
Waypoint pitch deck
Wealthsimple pitch deck
01
wtf are we building?
Getting started is the hardest and most exhilarating part. You can do anything, go any direction. It’s easy to get lost in the freedom unless you maniacally set parameters and constraints. To do so, you have to know your customers and their problems, prioritize those problems, and ruthlessly define your MVP accordingly.
02
how do we build it?
Now that you have a direction, speed is of essence. The turtle never beats the hare in software. The quicker you can get to customer 1, the faster you’ll validate, and more importantly, invalidate the core assumptions you made earlier on in the product lifecycle. To get there faster, you have to understand how to best work with your team, effectively explore your solution, and get good at avoiding rabbit holes.
Resources
1
Understand how to work best with your team.
Creating an environment in which my team could be successful was vital. My team organized in a "triad" with a PM, responsible for defining the problem and product vision, a UX designer, responsible for defining the solutions to those problems, and a tech lead, responsible for owning and implementing the solution. We also had 2-3 engineers who reported directly to our tech lead.
Once we had defined the roles withoun our triad and started fostering psychological safety, I tried to understand what my designer and tech lead really needed from me. This will vary for each person based on personality and experience level. The best way to understand is to ask.
To your designer, ask: what do you need to feel confident working towards a solution? What, in your opinion, defines a great PM?
To your tech lead, ask: what do you need to implement a great solution? What, in your opinion, defines a great PM?
Product Requirements Doc
Here's a great example from the team at Product Hunt.
2
Explore solutions.
We went from problems to solutions through workshops and brainstorms. After the brainstorms, I put together Product Requirement Docs (PRD) for each core feature in our system. I used the vision and defined MVP, as well as additional research into each more granular feature to write more detailed requirements.
Once we had a few design concepts we really liked, we put them in front of customers, gathered feedback, tweaked designs, and repeated until we had a holistic solution we felt confident would meet user needs.
3
Get to customer #1 as fast as possible.
You're limited in learnings until you have a product in the hands of customers. What users say they'll do is often very different than what they do. The real learnings begin when you have a living, breathing product with users who are trying to leverage it to complete their desired outcome.
The road to launch is full of rabbit holes. Constantly revisit your core assumptions and test features you're considering developing against those assumptions. Less is usually more. Unless you're 100% confident you need a feature, remove it from scope.
03
shipping it.
Measure progress and evaluate success to determine if your solution worked. Document your learnings and decide your path forward to continuously improve your product.
Resources
Defining product success template
These are the spreadsheets I used to create activation and retention cohorts that we used to measure our product's success. I also love Amplitude's deep dive on the North Star metric.
1
Clearly define success.
There's three core qualifications I would set for any product:
-
First value (measured through activation) - ensure that this metric aligns with users' intended first value in the product. It can be really easy to look at leading metrics that aren't as strong of an indicator of genuine usage.
-
Consistent value (measured through usage retention)
-
Commercial value (measured through revenue)
These are designed so you can understand, quantitatively, whether or not your launch was a success or not and to start benchmarking your product as you continue iterating and making improvements to it.
2
Prepare your go-to-market team.
We built the thing. The next step was to effectively sell the thing! To do that, we had to rally the organization around the product.
We created a product positioning guide that detailed:
-
Positioning
-
Pricing
-
Launch details
-
How it works
-
FAQs