How to not screw up your product launch:spend some time thinking about the go to market plan in advance
Every product team aspires to ship awesome products. My hypothesis is that a rigorous product development process is the main controllable ingredient to this. A tool that has been helpful as I think about this with my team is a specific product process (diagram above) with various documents depending on the stage of the product. These documents are
- The 1-pager product brief: typically built at the outset — defines the problem statement, use cases, how to define and measure success, resource needs etc.
- The solution details: architecture diagram / solution details — often owned by tech; could also include design research / strategy (owned by design)
- Go-to-market plan: Often conflated with “just” marketing / sales — I’m using this term a little more broadly to include things like customer support plan, monitoring plan etc.
- Product iteration plan: built after initial results have come in — how is the product performing, what is going well / not going well, how will we iterate going forward…
Will describe other aspects of this approach in other posts — for now, will focus on the “go-to-market” plan i.e. how to think about the act of shipping and scaling. In terms of where this fits in the overall process — at the point of writing this document — the problem statements are clear, user research is done, goals are set, designs (both engineering and UX) have been validated and code is being written and tested. The product is ready to ship.
A quick process note: this document and plan should be reviewed with the team well in advance of the shipping date. Ideally, it should be socialized with all the people and teams involved in the act of shipping — the engineering team, support, marketing, leadership. Start socializing well in advance, so that feedback can be incorporated (otherwise what’s the point?).
What follows is a set of questions that make up a good go-to-market plan.
How will you monitor this initiative?
- Metrics monitored: 1) It didn’t break anything (at launch, to ensure execution = intent) and 2) Its impact on customers/business (long term)
- Frequency of monitoring — how often will you monitor the key metrics
- Guardrails / Kill metrics: what level of variance in key metrics is acceptable vs. not. For example — at an API call error rate of 0.2% will cause us to investigate, while an error rate of over 1% will cause us to roll-back.
What are the unhappy paths? What are the sub-optimal scenarios, how are we planning to handle empty states and errors? For example: a certain segment of customers will have trouble (e.g. new to credit customers on credit monitoring apps) — what should be the messaging, UX and support plan for these scenarios.
What is the go-to-market plan?
- Tech timeline: Release timelines
- Implementation strategy: Will components be released all at once, or spread out in multiple releases?
- Are there any release dependencies? Are you depending on other components of the stack, if so — have you got those dependencies lined up? Are you a dependency for another system? If so — have you informed them of upcoming changes?
- Ramp up: Big bang to all customers or slow / iterative ramp-up? If latter — what is the schedule, and what must be true in terms of quality and response for subsequent waves?
- Customer support / servicing plan: Have we thought of common customer questions, and armed the support crew (could be customer support, engineering, product — depending on the situation) with answers
- Marketing (internal and external): What is the plan to market the feature to customers? This is important not only on its merits — everyone should understand the positioning, placement, distribution , pricing etc. In addition, from a technical perspective, often engineers don’t want to pulse a ton of traffic to new infrastructure before they get the chance to work out the kinks in real world performance testing.
What could go wrong? How will you mitigate those risks? It’s important to proactively think through various risks and how they could manifest e.g. legal risk, reputation risk, customer experience risk, financial risk etc. Equally important is a clear articulation of what you have already done to mitigate the said risk, and what you will do if the risk actually materializes.
What’s the next step if we succeed? If everything goes as per plan — what comes next in terms of iterations, new features, scaling plans etc.
What’s the next step if we fail? How do we gracefully exit, what will we do next etc.
Anything else you think about when shipping a product?
All views, opinions and statements are my own
