Being “outside-in”, “outcome-based”, and “market-driven” is particularly important for creating successful products. The problem is that just saying the words is not enough to help someone shift their thinking. For those of us who are already thinking this way, the phrases become touchstones or short-hand. For folks who are not there yet, these may sound like platitudes or empty words. I know many people who want to switch their roles from “do these things” to “solve these problems.” They have to change their organizations. This example may help get the point across.
I was part of a messaging conversation on my phone last month with three other people (a group MMS). Instead of seeing 3 names, I saw two names and one phone number – not a good way to identify the participants. Because I’ve helped create a messaging app before, I happen to have some insight into how the app is likely to work. When the app receives a message, it receives a “payload” which combines the message with other information about the message (data and meta-data). The payload including the messages and several phone numbers identifying the participants in the conversation. The app then checks the list of contacts on my phone – and for each matching phone number, replaces the phone number with the person’s name. The unmatched phone numbers stay unmatched.
I’m mentioning how the app might work on the inside, because that’s the situation facing people with an inside-out perspective. Specifically because they know how it happens to work – they frame discussions around making changes to what a thing does by changing how it does them. The curse of knowledge undermines market-driven #prodmgmt.
I was able to infer the identity of the unnamed participant because of the context of the conversation. I started the process of adding that person to my contact list. I entered the person’s name, and the messaging app pre-populated the mobile phone number for me. Very convenient. My brain shifted into “requirements management” mode for a moment, and I imagined writing a user story.
As a participant in an SMS conversation, I want to be able to add unidentified people to my contact list…
The important missing piece of the user story fragment above is the intent. As a persona, I want to do some activity (with some frequency), so that I realize some benefit. At first glance, it looks like there is intent – “to add…” but that’s not intent, it is only activity. Don’t confuse action for intent in user stories.
A common mistake would be to write
As a participant in an SMS conversation, I want to be able to add unidentified people to my contact list.
This story has the “feel” of a programmer who is writing the code first, and then documenting the design second. Intuitively, you want to be able to change context from what you’re doing (participating in a conversation) to do some tidying-up (adding someone to your contact list). People like to organize stuff. Especially programmers.
That doesn’t seem quite right – the intent seems off. It feels like someone has already decided this feature is required, and as part of working their way through the list of imagined features, is shoehorning their “inside out” desire into a story syntax designed for communication of discovered customer intent.
As a participant in an SMS conversation, I want to be able to add unidentified people to my contact list so that I can keep my contact list current.
- My contact list is missing this person vs. I need to know the identity of this person.
- My phone does not ring loudly enough vs. I am not noticing incoming phone calls
- I need a faster horse vs. I need to get to my destination faster.
As a participant in an SMS conversation, I want to know who all the participants in the conversation are.
Maybe “knowing who someone is” requires more than just “Carla” ; maybe it requires “Carla – you spoke with her about wearable technology at the event at the Citadel hotel on Saturday night.” Have an elegant way for the application to inform you about which Carla it is and how you’re connected.
These are all creative means of solving the problem which your team is not as likely to explore when you tell them you want to “update a contact list.” You miss out on an opportunity to innovate – to invent something valuable – by focusing on an inside-out description of a problem manifestation.
Focusing your product creation on solving problems is subtly but powerfully different than focusing on creating features.
Your team can only make what you ask for when you tell them how.
Your team can do truly amazing things when you tell them why.