Outside-In User Story Example

Blog: Tyner Blain

thumbnails in a messaging app identifying conversation members

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.

JSON extract of messaging payload

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.

organizing colored books on shelves

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.

automatic recognition of a person

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.