Does this sound familiar?
- Write document ‘A’
- Copy most of its contents into template ‘B’
- Rework same content into slideshow ‘C’
- Copy slide images into document ‘D’
- PDF and circulate an executive summary of document ‘D’ for feedback from EVERYONE IN THE COMPANY
- File documents A-D in a folder no-one will ever inspect again
If so, read on…
We’re looking at the kinds of information that specific groups of people need to know during the lifecycle of your product and why they’re so interested in the first place.
Last time we covered the steps from idea through to convincing people to part with some cash to build it. Now we’re going to look at building it and onwards through launch to review.
Build stage: what do we need to make? #
Objective: to build the solution to the problem we originally identified
Audience: the build team, developers, engineers, quality assurance
You’ve managed to convince those holding the purse-strings to part with the cash, now you need to turn that vision into reality. Bear in mind that it’s rare that your idea will make it to production precisely as you envisaged it. On the plus side, you have the benefit of a group of great minds – your developers and engineers – whose job it is to build great products from great ideas.
You are not a designer so the important role you play here is to ensure the project team understands the problem and its context as well as your idea for solving it. While you must not be overly prescriptive, you do need to let them know of any constraints or quirks that make certain design choices for you, for example “must work on Android and iPhone web browsers”. Clarity of communication is key here; talk things through with your team to resolve ambiguities and document your collective design decisions so that you’re all working to the same plan.
Questions to ask at the build stage #
- In what context will the product be used?
- How does the product need to work for the customer?
- What do Development / Engineering need to know to ensure they build the right thing?
- How will they know it’s good enough to finish the project?
- What’s the bare minimum set of features you need for a commercially viable launch?
- What else would do if you had more time or budget?
- How will the customer ‘unpack’ and start using the product?
Promotion stage: what the story (morning glory)? #
Objective: to get the word out before during and after launch
Audience: marketing, PR, potential customers, journalists, analysts
Here is a situation where you can rework some of the material you’ve already produced at the concept stage. Right back at the beginning of the process, you identified the problem, who it affected and how much of an impact it made on them. You also described how your solution to that problem was unique or differentiated itself.
You can use all this raw information with your marketing and PR people to weave an engaging story about your product. You can also ensure you tell it to the ones who will be most interested in listening, namely those with the original problem, and journalists and analysts who have similarly identified and examined the same problem. And because you understand the different types of people with the problem, you can help your marketing team tailor the story to use the audience’s language.
Launch stage: how do we get the product out there? #
Objective: to ensure all activities are coordinated
Audience: anyone directly involved
This is arguably one of the trickier stages in the process because you need to draw together several threads of parallel activity and tie them together. Much has been written about effective launches (see Launch Clinic for example). At its simplest, a good product launch ensures that the people most likely to be interested in your product understand what it is, what it does, how it solves their problem and that it is available. Similarly, a good launch ensures that everyone in your organisation touched by your product understands the role they need to play to achieve that.
Questions to ask at the launch stage #
- What do sales need to know to sell this?
- What do your partners and resellers need to know?
- Elevator pitch
- Benefits and features
- Pricing
- Discounting rules
- Commission structure
- Licensing model
- Competitive strengths
- Objection handling
- Who should sales and partners contact for help when selling the product?
- How do we take orders for it?
- How do we deliver the product to the customer?
- How will Tech Support / Customer Services need to prepare to support it?
- What information do you need to publish and to which audiences?
Review stage: what did we do well and where can we improve? #
Objective: to check we did what we set out to do
Audience: senior management, peers
There are two main areas of review: how well you executed the launch (process) and how well your product performed financially after launch.
The first you should do pretty soon after launch while memories are still fresh. Get the main people involved in the launch to fill out a quick survey to score how well each of the launch activities went. Get them around a table for an hour or so and share with them the scores. Pick out the ones that went really well or really badly and understand why. Discuss how to ensure the really good aspects can be repeated for future launches, and figure out how to rectify the bits that went badly for next time. Finally, make sure that the product manager coordinating the next launch learns from these lessons.
Now, you know how there’s no such thing as a free lunch? Well, there’s no such thing as a free launch either – you’re going to have to demonstrate at some point how successful you were in converting the money you were given originally into a larger sum of money. To do this, you’re going to need to dig out the business case and compare it with what actually happened.
Now it’s not necessarily a good thing, but the majority of business cases I’ve seen tend to be over-optimistic on how quickly the capital investment returns meeeeeelions of dollars. However, if there is a larger than usual discrepancy between what you were expecting and what actually happened, then it will be important to investigate why. Because someone’s going to ask you. Another way of assessing project success is how long it takes for it to break even. This is a great fall-back position as it demonstrates that you’ve at least not wasted the money.
You may find it makes more sense to review the business case perhaps three, six, nine and twelve months after launch so that you can separate the blips from the trends.
Questions to ask at the review stage #
- How does our actual financial performance compare with our business case forecast?
- How effective was our launch?
- How satisfied are customers with the product?
- How many support tickets have been raised?
- How many bugs have been logged after we released?
- How could we improve the product and process for next time?
I hope this little two-parter is helpful. As always if you have any questions or would like some more detail, feel free to ask in the comments.