Agile Product Management with Scrum : Chapter 2 : Product vision
In which I summarize the second chapter in Roman Pichler’s Agile Product Management with Scrum, on envisioning the product.
——
Chapter 2 Summarized
Here’s what I took from the second chapter of the book.
The vision describes why the project is being undertaken and what the desired end state is.
Qualities of the product vision
(These are qualities of the vision, rather than qualities of the envisioned product.)
- Shared and unifying
- Broad and engaging
- Short and sweet
Shared and unifying
Everyone should buy into the vision.
A great way to create a shared vision is to involve the Scrum team and stakeholders in the visioning activities.
Broad and engaging
Resist the temptation to provide too much detail or to over-specify the product.
The product vision leaves a lot of room for creativity and emergence in the development of the product, but has enough to it to excite and motivate.
I do not know exactly what it is, but I know enough about what it might be that I am excited to figure it out.
Short and sweet
The product vision is not a feature list and contains no unnecessary detail.
It’s an elevator pitch.
Bootstrapping product vision
- Pet projects
- Prototypes and mock-ups
- Personas and scenarios
- Vision box and trade journal review
- Using Scrum to build the product vision
That last idea is good to remember — Scrum can build all sorts of things, so long as the artifacts it builds have value to the organization. Scrum doesn’t have to just build working software, it can build other kinds of artifacts, so long as those artifacts are “working” in this sense.
Qualities of the envisioned product
Basic, performance, and delighter attributes
Pichler advances the Kano model of product attributes. Products need basic attributes or else they are useless. (Say, users are able to log in to the application.) Performance attributes are nice and the more performance the better. (Say, the application loads and responds quickly.) Delighter attributes are market differentiators that define breakout products (say, the calendaring application automtically schedules to-dos onto the calendar; see also Timeful.)
The challenge is to effectively mix basic, performance, and delighter attributes to arrive at a compelling product at a viable price point on a timeline that will deliver value before the market changes out from under the product.
Simplicity
That whole thing about how the best design is not one that includes everything that it can but is rather the design that takes out as much as it can, getting the product down to its essence.
That thing 37Signals (now, Basecamp) was talking about with “Do less than your competition to beat them.”
- Ockham’s Razor
- Less is more
- Simple user interfaces
Tradeoffs as powerful
In considering product attributes, understand whether you would
- Sacrifice other attributes for this attribute
- Try to keep this attribute
- or Readily sacrifice this attribute to gain other attributes
The product roadmap
A product roadmap … shows how the product is likely to evolve across versions, facilitating a dialogue between the Scrum team and the stakeholders.
A product road map should state for each version the projected launch date, the target customers and their needs, and the top three to five features.
Use a realistic planning horizon, like 6-12 months.
On product variants and platforms
Potentially quite powerful, but avoid the bloat of too many variants. Grow a platform organically to avoid building platform cruft that you don’t need.
Anti-patterns
Again, one of my favorite features of the book is its calling out pitfalls and common mistakes.
Anti-pattern: No vision
This anti-pattern arises commonly when product development starts without a product vision.
This might be because the product is built as a series of responses to one-off out-of-context feature requests without thoughtfulness, considering saying no, and merciless refactoring. The result is a “feature soup” or at best a product hobbled by creeping featuritis.
Avoid this anti-pattern by having a vision, gaining buy-in for that vision, and mercilessly filtering feature requests and ideas to fit with the vision.
A sure-fire way to create a terrible, unusable product is to simply implement every feature asked-for in the way it was requested.
Anti-pattern: Prophecy vision
The problem with predicting the future is that you may be (indeed, will be) wrong. Prophecy visions are visions prone to be spectactularly wrong. The solution to this is to select a narrow set of customer needs, release quickly, and inspect and adapt. It’s harder to be as spectacularly wrong on nearer timescales in narrower scopes and anyway the consequences of wrongness are lesser the sooner you find out.
Anti-pattern: Analysis paralysis
In this anti-pattern excessive up front analysis and planning gets in the way of actually doing anything.
Instead of excessively attempting to predict and analyze potential market feedback and outcomes, get a product out there and analyze actual feedback and outcomes.
Anti-pattern: We know what is good for our customers
In this anti-pattern the organization invests in building a product no one needs or wants because it fails to incorporate customers and users into the development process and to listen to their feedback.
Involve stakeholders in visioning, in sprint reviews, and in the development process to avoid this anti-pattern.
Anti-pattern: Big is beautiful
In this anti-pattern the product attempts a big-bang launch with more functionality at a great cost in time and expense only to suffer a high risk of failure.
Avoid this anti-pattern by building minimal viable products, releasing them early, and attending to feedback. If you’re not uncomfortable about how minimal your product is, you’re doing it wrong.
——
This post is part of a series
This post is part of a series of posts about chapters in Roman Pichler’s Agile Product Management with Scrum.
-
Chapter 2 : Product vision (this post)
——
Read the book
This is a great book; you should read it.
I hope my summary is helpful, but it does not do justice to the nuance and detail in the book.
——
Acknowledgements
Cover photo: (a)artwork Myst telescope via CC-BY-NC-ND-2.0.