Have you ever been asked to develop a product feature without understanding the underlying goal, or how it fits into your organizational strategy?
The following checklist may be helpful in ensuring you’re clear on your organization’s context, so you can be sure what you develop will support your organization’s overarching objectives.
Because product development resources exist to support business objectives, a product’s clarity can only rise to the level of clarity in the overarching organization’s mission, strategy, and objectives.
Be sure your organization is clear on each item before attempting to define any later one — the moment something isn’t clear, or people aren’t aligned, you know that’s the next thing that needs to be defined.
1. Purpose “This is why we exist.”
2. Strategy “This is how we will accomplish our purpose.”
3. Objectives “This is how we’ll gauge if our strategy is fulfilling our purpose.”
4. Build “This is what we’re building.”
5. Backlog “This is the order in which we’ll build it.”
6. Development “Here’s what we’re building…what are your thoughts?”
7. Released Product “This is how we will release it.”
8. Value to Customer “We have something that can help you.”
9. Positioning of Value to Customer “This is how we are positioning to users and customers.”
Sample questions to ask before building something:
- Why will the world be better off with our product?
- Does this support our overarching business strategy? What is our overarching business strategy?
- Is this the most important thing to work on, today?
- Where should this be sequenced, relative to our current backlog of work?
- How much time and attention will this require, from business and tech teams? Will this distract us from more important things to be focused on?
- Who has voiced that this is important to them? Are they a paying customer, or have they committed to it?
- Do we very clearly understand the jobs-to-be-done?
- Have we articulated alternative solutions or paths? What did the user do last time this issue arose? (Have they put forth any effort to find something better in the past?)
- What would it take for users of alternative solutions to switch to our solution?
- How will we help people be comfortable switching to a new process or platform? (Given people’s preference for familiar things, even if those things are suboptimal?)
- Who do we need to stop listening to, once the product matures in the arena of one user group (e.g. early-adopters), and it needs to change to be considered a viable solution by other, larger user groups (e.g. early majority or late mainstream users)?
- When are we no longer a niche product? Are we better positioned being known for only one thing, or multiple?
- Is our solution simple enough (including it’s name, and our messaging) to be memorable and easily mentioned?
- If we’re the relatively sophisticated offering, what’s to keep a simple, cheaper solution from disrupting us?
- How will we communicate about the problem, and our solution?
- What maintenance or ongoing support will this require? (Both from tech, and business support?)
- Will portions of the jobs-to-be-done are likely to change over time?
- What portions of our solution will change over time?
- Have we looked at some sample product plan templates, to consider things we may have missed (e.g. the customer forces, buyer’s journey, or lean product canvas)?
- Have we received honest feedback about our idea?