Global Product Management Talk: Writing Compelling User Stories
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.
Comments ()