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.
Contact Manager
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 product management.
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.
A less-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 so that I can keep my contact list current.
Again, this smells like an inside-out story. Imagine a user has told you they want this. This still would be an example of focusing on the problem manifestation (an out-of-date or incomplete contact list) instead of the problem – identifying people. Users almost always fixate on problem manifestations, versus underlying problems:
- 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.
Underlying Intent
The underlying intent of your user (or stakeholder) is the requirement. When you express requirements inside-out (with a presumed design approach) you miss out on opportunities to make a markedly better product. How you articulate the requirement unequivocally biases and constrains the solution-space within which your team will solve the underlying problem. Consider our example, of not being able to identify all of the participants in the conversation.
When you give your team “As a participant in an SMS conversation, I want to be able to add unidentified people to my contact list.” they will design a way to do exactly this. They could craft an elegant workflow where the user long-presses on the phone number of the unidentified party, and the phone presents a minimally disruptive interaction – perhaps adding only first and last name – and then returns the user to the conversation. The phone may even create a notification which pops up only after 5 idle minutes pass, indicating the conversation is complete – encouraging the user to provide additional information. Sounds great, right?
Here’s the problem. The user does not want to update their contact list. The user does not care about having a contact list. The user wants to know who is in the conversation. Let’s rewrite the story like this:
As a participant in an SMS conversation, I want to know who all the participants in the conversation are.
Now your team can design things like the following solution to the underlying problem. If there is a contact list, and the phone number matches an identity, use it. If not, update the contact list once the identity of the participant is discovered. Attempt to infer the names of the participants from the context of the conversation (and other conversations including the same phone number – even from other users. Perhaps the platform provides backup and restore capabilities, including saving messages – that data can be mined for the identity of the person associated with the phone number. Perhaps your messaging app is part of (or owned by) a social network or some other product or service which has an index mapping identities to phone numbers – now you can look it up directly. Go one step further – don’t just infer the name, find the profile picture associated with the participant. Find the participant’s avatar.
Then automatically update the messaging app to replace the phone number with the avatar and/or name. Use whatever technique is most elegant to “remember” identities in the future.
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.
Conclusion
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.
Uncovering true problems is quite a task and takes a strong will. Most folks talk about “solving problems” these days and then proceed to list features or themes.
My current theory as to why this happens is primarily because people don’t know they’re doing it. So while it’s true, by definition, that “the button isn’t red” is in fact a problem (kinda), it’s highly unlikely it’s THE problem.
By that line of thinking, most feedback from the field will come back to product as “make the button red.” Then everyone will stare at it, and see how many people want the button to be red. There will be thousands of votes cast. Then it will ship, and no-one will have a clue as to how to correlate it back to actual results.
Because the button being red isn’t THE problem. There’s an underlying reason why that’s being requested most folks miss. But it still goes on roadmaps nonetheless and gets bucketed alongside a bigger group of features called “Button Enhancements” and attached to Q3; and everyone is happy and feels good about themselves for creating data- and customer-driven products.
But, really, the entire process is flawed due to a lack of understanding of what they are actually doing — and the most important product question of all: Why?
You’re exactly right Adam! After receiving feedback of “make it red” we need to understand why. What we need to do is ask “how would making the button red help you?” or “what problem does that solve?”
Scott, thank you for yet another great article. A few questions though. In the article you mention this “Here’s the problem. The user does not want to update their contact list. The user does not care about having a contact list. The user wants to know who is in the conversation” however it is unclear how you have arrived to this conclusion. I am curious what preceded this insight? Was it past knowledge / experience or some sort of a research with app users?
Secondly, do you have any personal criteria that help you determine whether you are working with a design or intent? The example of “faster horse” vs “get somewhere faster” is good but I am not sure the difference is always going to be that visible. Do you have any personal recommendations on how to determine whether you are dealing with a design?
Oh, I almost forgot to link here to the article I wrote inspired by your question:
http://bealprojects.com/products/how-to-make-sure-youre-dealing-with-the-real-problem-and-not-just-a-problem-manifestation/
I’m sure Scott and others will have valuable “tips and tricks” to share in future articles, but hopefully mine will give you some food for thought as well.
Nice article Scott, it is a common tendency to jump to the solution rather than eliciting the problem first. The article is helful not only in product management but in other aspects like requirement analysis also.