Yesterday, I was the guest speaker on the Global Product Management Talk hosted by Cindy Solomon. For yesterday’s show, Roger Cauvin was the co-host. We were discussing how to write compelling user stories. As many of you know, this is a topic that I’ve covered in-depth throughout September. Roger raised an interesting point during the discussion that has since caused some confusion. It’s important enough that I’d like to address it here.
In the talk, I described the different components of a user story as the who, the what, and the why:
- As a specific type of user (the who), I want some action (the what), for some benefit (the why).
I was discussing the common mistakes people make when writing user stories and I mentioned two that I’ve written about in the past here – not specifying the type of user and not including a benefit. I argued that too many product managers focus too heavily on the what and not enough on the who and the why.
Roger pointed out that by focusing too much on the what and not the who and the why, you can create an environment in which your engineering team only does the bare minimum to deliver the product requirement. If you don’t communicate the who and the why to your team, they don’t have the context necessary to go above and beyond when delivering on the what. Roger argued, and I agreed with him, that this is not good.
However, the way Roger described this concept, only delivering the bare minimum needed to meet the product requirement, made me think of the concept Minimum Viable Product or MVP from the Lean Startup. While Roger was pointing out a situation that you want to avoid, I was concerned that listeners might confuse his explanation with the MVP concept – a great concept that all product managers should strive for. But I think by trying to clarify the two, I created more confusion.
So I’m going to try again here:
I believe Roger’s point was as follows: If you don’t communicate why you are building what you are building, you will only get exactly what you asked for. You remove any possibility of solving the problem in a better way.
Whereas the MVP concept describes the least amount of product you have to deliver to satisfy a market need.
In both cases, we are talking about building the least possible. In the first, we are talking about an engineering team taking orders and doing just enough to get by. This is clearly not good. In the second situation, we are talking about a company building the lightest weight product possible to satisfy a market need in order to quickly learn what’s working and what’s not working. In this case, it’s not about just getting by, it’s about building just enough to learn. This is good.
I’ll update the post with the audio and transcript of the talk when they are available. In the meantime, the following resources might be helpful:
Did you listen to the talk? What did you think? Was it helpful? Please share in the comments.
Thiago Oliveira says
Great talk. With a number of user stories I am reviewing at the moment, it made me pay special attention on who we are building each of them for and what should be the real benefit. The ‘what’ and ‘how’ will surely be carried out more easily when the context is absolutely clear. Thanks.
Rivki Locker says
I did listen to your talk (and was somewhat confused during the discussion you are referencing here… so thanks for clarifying). It was a very informative talk as our organization moves to an Agile framework. Thanks!
Teresa Torres says
I’m glad you enjoyed the talk and that this post helped clear up any confusion. Best of luck transitioning to Agile. You might find this post about User Stories helpful. Everything You Ever Wanted To Know About Writing User Stories
Roger Cauvin says
Teresa, it’s been over a year since we had this conversation in our Global Product Management In clarifying some of the points we covered, you really hit the nail on the head and stated it beautifully:
“If you don’t communicate why you are building what you are building, you will only get exactly what you asked for. You remove any possibility of solving the problem in a better way.”
The other point is sort of a corollary and wasn’t so much about MVP, but about what constitutes a “requirement”. My definition of “requirement” is: a requirement specifies the least stringent condition that must hold to solve or avoid a prospect problem.
For example, if the problem is that it takes too long to renew registration for your automobile, and “too long” means greater than one minute, then the requirement is that the system should enable the registrant to renew her registration in a minute or less. Stating requirements this way communicates to designers and developers why they are building what they’re building, and gives them maximum flexibility in solving the problem.
This model of requirements concepts explains more.
Anyway, a much belated thanks for writing up this summary of our talk and for clarifying some of the points.