Drift.com’s Product Launch Framework
This is a guest post from Matt Bilotti, Product Manager at Drift.
Getting a new product out the door is hard.
There are dependencies across the engineering, design, and marketing teams. There are limitless ways you can continue to improve something before it’s released. Then there’s scope creep – that itchy feeling when you want to work on something just a little longer until it feels more right.
But we’ve come up with a framework to make the product launch process easier. Here’s how we put all the pieces together, from customer feedback to team resources, to ship fast and ship often.
There are dependencies across the engineering, design, and marketing teams. There are limitless ways you can continue to improve something before it’s released. Then there’s scope creep – that itchy feeling when you want to work on something just a little longer until it feels more right.
But we’ve come up with a framework to make the product launch process easier. Here’s how we put all the pieces together, from customer feedback to team resources, to ship fast and ship often.
Build your product launch plan with our framework
The framework we work with at Drift tightly revolves around strong user stories and then testing what we build against customer feedback.
These are the three questions we ask when we’re thinking about releasing our product to the world:
- Would the product solve somebody’s pain in its current state?
- Are there any remaining dependencies?
- Does the product actually work? Versions of this question include: Does this feature function the way we promise? Has it been stress tested enough that we’re confident it won’t break the moment we give it to somebody?
Would the product solve somebody’s pain in its current state?
Before we build anything, we establish whether what we’re building is useful to our customers’ end experience. Does it presently solve a pain? Does it complete the Job To Be Done (JTBD)?
JTBD has became a popular and effective framework because it makes product teams replace assumptions about users with an actual situation, user motivation, and an expected outcome. It’s a form of user stories that is more tightly linked to specific motivations and desires.
If we’re not building something that makes a measurable difference to them – if it doesn’t help them work faster, more efficiently or make them feel more confident, then we don’t ship it.
It’s easy to fall prey to bias. You might have been working on your solution for a while. You might have sunk a lot of time, money, and effort into it. But if you can’t all honestly answer “Is this useful?” from your customer’s eyes, you’re wasting everyone’s time.
Are there any remaining dependencies?
Is the marketing team ready and lined up to drive more awareness and engagement for what you’re building? Are the front-end and the back-end teams set up to collect the right data? Are all states handled and accounted for?
In other words, is everything in place to solve this particular problem you’ve been working on? If not, you still have dependencies left to take care of.
I speak from experience here.
I was once on a team that made the mistake of launching a new feature that looked complete on the surface.
What we didn’t do was account for how the front-end would pass data over to the back-end, leaving some of our customers with inaccurate data. Given that this is what they were paying us for – good data – it’s not surprising that they left us a few months later.
We had tested our new feature, but we hadn’t really stress tested it. That ended up having real dollar value consequences for us.
That leads us to the final question in the Product Launch Framework…
Does the product actually work?
It’s happens often, but that doesn’t make it any less painful. Will your new product break or interrupt your customers’ core user experience?
That’s a big question, and it takes some commitment from everyone to answer it. We rely on user stories to get the team involved in this phase.
As ProdPad’s Andrea Saez suggests, writing user stories is everyone’s job. “User stories force you to think from your user’s point of view, and that’s a good thing,” she says.
The benefits of user stories really shine when teams beyond product and engineering start writing them. They interact with the product differently, and bring up issues that you may not yourself see.
Everyone should test the new product or feature while it’s still in staging. Everyone write up user stories (or JTBD), and document them in ProdPad or whatever your product toolkit is.
When we’re sure the product will work just fine in 95% of situations, we ship. Then we stay on alert to fix up edge cases.
What if you have unintentionally expanding scope
Do any of these look familiar to you?
- A product manager gets obsessed with edge cases and extra value. He continually asks for small additions each time he sees progress
- A designer jumps in and says, “Let’s also do this to make the experience super duper awesome!”
- An engineer wants to add her own flair before shipping and add a bit more functionality that she thinks will be useful
It’s easy to default to adding all of these small things. But over time, they add up to 20 things that take another two hours each and extend the release of a feature another week.
We generally don’t let scope get to us, but it takes discipline. We get our product out fast and wait till we have customer feedback to work on further iterations.
It gives us a chance to validate our assumptions and user stories with real usage data and comments. Our customers are usually the ones that tell us what would make a big impact to them, so we don’t spend too much time working on the small details that don’t matter.
This three-part framework helps us avoid that and keep us shipping. Once you say ‘yes’ to all of the above, send that product out the door and start getting customer feedback.
No need to wait for anything else.