3 Ways to Help Your Product Team Begin With the End in Mindby
When beginning a new release, feature development phase or sprint, having a shared understanding of the end goals across a large team is a challenge. But there are some simple tools that I’ve found really help product teams start off with the end in mind.
Write a Mock Press Release. This is a method from Amazon’s Working Backwards process. Draft an article that describes what you are building and why it is valuable as if you were about to release it. This forces you to take the perspective of someone outside your organization asking so what and who cares? Put yourself in the shoes of someone reading about the release with only a vague idea about what your company does. What would you say if you were being quoted by an analyst right now?
This is a great conversation starter about the larger questions of Why? If you get a lot of confused looks from your team, that’s a good cue to tighten up the message and sharpen your thinking. Better now than midway through the cycle.
Or just before release.
Another benefit is that down the line, you will be able to reuse snippets in the real press release. The marketing and PR folks will love you for it.
And if you’re feeling adventurous, write the FAQ document based on the type of questions you anticipate.
Sketch an Opportunity Canvas. Tools like Lean Canvas or Business Model Canvas allow you to easily visualize business models for new products on a single page. But you can also use a similar canvas when looking at new features for an existing product.
An Opportunity Canvas has a similar format based on nine boxes with some modifications. It’s a great way for product teams to collaborate with people in other parts of the business early on to answer important questions such as:
What problem does this solve?
How do users address that problem today?
What business metrics will be affected?
Sticky notes on a whiteboard work for small teams in one location. Distributed teams can easily use their favorite on-line document sharing format.
Create Sprint Goal Bulletin. There’s usually a lot of communication and definition at the beginning of a new release or at the onset of new feature work. But it’s also important to give each sprint or iteration its own identity. So I like to start each sprint by reviewing a 1-page bulletin that defines the goals with the team.
Roman Pichler has a great sprint goals template that you can download here. The 1-page template defines what should be achieved, how we plan to validate the work and the metrics we’ll use to confirm that the goal has been met.
What tools and methods work for your team?by