Category: Build Things People Want

ICP Explainer pt 2: Build Their Dreams

Posted on Posted in Build Things People WantTagged , , , ,

One of my favorite product tools, especially when talking to non-product folks, is the Ideal Customer Profile.  That is because it finds that perfect overlap between the deep history of targeted marketing and easy to understand explain metaphors.  Too often when I am talking to business leaders, senior engineers, or customer support staff the theory is too much.  They want a quick mental model they can align their thinking with.  ICP is exactly that.  Also, I get to make fun jokes about Insane Clown Posse.

Fundamentally, an ICP is answering the questions “who are we building this for” and “what problem are we solving for them”.  Which means it is super powerful for when we are having tradeoff or prioritization conversations.  With many of the startup founders I have worked with we have used an ICP to focus limited energy in both product and sales.  With larger companies, I have used to clearly understand who we are saying ‘no’ to and why as well as force conversations about purpose drift.  Super useful.

But also, super dry.

I can give you examples of what an ICP is and then a step-by-step process on how to build them.  I can give you a bunch of anti-patterns and failures with the related cautions.  I can give you all the “it depends” across industries and business models.  And you will get that down there if you want to scroll.  But that’s boring at it doesn’t help with the goal I actually have with most product tools: mental models that help us communicate.

We are writing a novel.  A story of a person with a great need.  One day our main character wakes suddenly up in the middle of the night, sheet damp with sweat and a great anxiety gripping their chest.  They were dreaming of something that would solve their biggest problem, and it was right there, within their grasp.  But as the dream slides away, they are left with a pressing certainty that they will never find the solution.

What is the problem they are having?  What relief will they feel when they solve it?  What are the characteristics of them, as a character, that makes that problem so prominent it is waking them in the middle of the night?  Who are they?  That person is your ideal customer.  They are deeply motivated.  They have a real tangible problem.  And solving that problem will create deep meaningful relief.  The ICP isn’t a mishmash of your existing customer’s characteristics.  It’s not a set of demographics that describes a huge swath of the population (which is somehow always a woman 35-45 with 2 children named Jennifer).  And it can be expressed crisply with clear things it isn’t.

B2B and B2C examples

So, let’s walk through a couple examples and then we can talk about how we build it.

  • Online consumers looking for rare or hard-to-find books (Amazon of the early aughts)
  • Families looking for interactive and collaborative games (Wii)
  • Sales leaders with complex and consultative sales processes looking to organize their sales team’s time and focus (salesforce.com in the early aughts)
  • Hospital and Health System marketers looking for HIPPA-compliant and expert website development and online marketing (CMS company I worked with)
  • Developer-tool companies looking to connect meaningfully with the developer community (social media startup I worked with)

With one of these clear descriptions of who we are serving and what problems we are solving for them I can test out what we should and shouldn’t be doing.  Let’s focus on the complex and consultative sales process tool.  I’m building a product that serves the sales leaders.  I have gotten a request to create marketing attribution fields (where the lead came from).  Do I build it?  Does it help the sales team sell?  Sometimes knowing where the lead came from can help open a conversation.  So I don’t need that information for marketing attribution, I need it to help the sales team start a conversation.  Does it help the sales leadership team?  Yes, knowing which channels are resulting in better sales helps me structure my team’s focus.  So the reason I am building this feature has changed.  I have clarified why I am building a feature (marketing attribution) to the needs of my primary users.

Anti-Patterns

To better understand how to use this tool, it’s important to start with what it is not.  It is not a buyer persona.  This is not the tool you use to fill your sales pipeline or prospect.  Buyer personas are super useful and often contain some of the same demographic and psychographic elements.  However, buyer personas are about who you are targeting with marketing and sales messages.  They will be a lot broader than an ICP because while you can target firmographics (the characters of a company) and demographics it’s a lot harder to target pain points.  Buyer personas are about authority, timeline, budget, and need.  They are a point in time about that sales process.  ICPs are an idealized set of characteristics about the perfect customer, one you will almost certainly never meet.  They are needs forward not personal characteristics forward.

It’s not who we want to be when we grow up.  It’s who we want to be right now.  If you are currently looking at horizon 2 or 3 explorations, you want to develop an ICP specifically for those experiments and test against it to see how you are getting penetration.  Often startups will start with an ICP and test to see if they get traction within that persona.  If they don’t then they tweak the ICP.  Companies with an existing customer base should have an ICP for their core business and then experimental ICPs for potential innovation that are adjacent to the core business.  I sell into hospitals and I want to experiment with selling into other highly regulated businesses, that is a new ICP and I need to better understand the demographics and pains of that new customer set.  Large companies may have multiple ICPs for their core business, like the Fortune 500 company I worked with.  The mistake is muddying them together into one ICP.  That quickly becomes an “everything for everyone” model.  Your ICP must have someone you are saying “no” to.  Sub divide to where you have product/market fit (PMF) even when, often, it is the same product across multiple PMF models.

It is not a current customer profile like account management will use.  Nor will it be user journeys that UXR and product will develop.  This isn’t how the current users interact with the current offerings.  It’s about what the ideal customer needs because of the deep need we are solving for them.

Similarily, in B2B, you must be conscious that your buyer isn’t always your user.  So much like the sales leadership vs sales team example above, the ICP is incorporating all those people together.  The problem you are solving is the intersection of the needs of the buyer and the needs of the user.  You can’t focus all on one or other.

Building an ICP

We are going to go about this in this pattern Pain Points -> Attributes -> Demographics Profile

To build an ICP start by answer the question “What problem are we trying to solve”?  It may be easier to reverse this question and ask “Thinking about my most ideal customer, what problem do they have that they currently find unsolvable”?  Write it all down.  Then go through each problem and statement and ask “do I want to solve this problem?” until you have a set of problem statements (customer pains) that you want to solve.

Now having a problem statement, you can start to think about characteristics of a customer with that problem.  If you have existing customers, this can be looking at commonalities of those customers that are related to the problem statement.  Here is my handy cheat sheet of characteristics to segment based on:

Now you have a profile.  Test it.  Look at each attribute and say “is this really compelling?” and “does this change customer motivation?”.  Must like all marketing profiles become, well, me.  It’s easy to just reduce yourself to the most common demographic properties of your population.  The name Jennifer was really popular in the 80s, women 35-45 have a lot of buying power, and that demographic is really likely to be married with 2 kids.  None of those characteristics are likely to be compelling to any particular problem statement.  I don’t need software to organize my kid’s schedules because I am in my 40s and married.  Having kids is compelling.  But likely being a busy professional and upper income are more impactful on that need.

Application

Once I have a ICP that I have walked around the organization it become a foundation for conversations we have with stakeholders and inside the team.  Does this feature help our ICP?  What are we saying no to?  Do our recent customers look like our ICP?  If there is slide, what is it and does it mean we need to adjust the ICP or we are starting to muddy our value proposition?  How recently have we talked to a customer who looks like our ICP?  What needs did they have that we aren’t currently solving?

Note: I don’t use AI to help write my posts or create example pictures. The segmentation cheat sheet is my creation and is also present in my Build Things People Want talk.  I did use AI  to create the header image, in this case ChatGPT with the prompt “create an image of glenngarry glen ross in the style of insane clown posse”.

ICP explainer: Segment the World!

Posted on Posted in Build Things People WantTagged , , , , , , ,

One day, a few years ago, I was chatting with an enterprise architect about some of the prioritization and focus issues the team was facing.  I told him “our real problem is that we don’t know our ICP”.  To which he paused for a long beat and said “Insane Clown Posse?”.

Fair enough.  I grew into product building at an early B2B CRM company before the rise of salesforce.com steeped in Glenngarry Glen Ross, Alan Cooper’s personas, and Angus Jenkinson’s customer segmentation strategy.  I have a coffee mug that boldly proclaims, “Ritalin is for closers”.  He grew up bleeding his ears with death metal while generating beautiful code.  Fair enough. An Ideal Customer Profile (ICP) sits at the intersection of emerging marketing trends and deep thinking about product intention for who we are selling to. Let’s break it down.

A Brief History of Targeted Marketing

Back in the late 90s and early 00s we were going through a major transition in how we thought about marketing and sales, driven by the move from mass marketing to personalized marketing enabled by the internet.  There was a deep divide between large companies, who were trying to serve everyone, and small companies, who were embedded in the needs of their community. Now instead of just blasting a message “drink my sugary beverage” with compelling images and social pressure, you could target certain demographics with marketing, and products, specifically suited to their needs.  By the early aughts, the internet made it possible for small producers to find their niche markets and customers to be more exacting in their needs.  Webpages popped up to serve these needs.  Instead of having the choice between two sugary carbonated beverages, consumers could demand, and find, a wide assortment of specialty products: probiotic, low sugar, fruit juice based.  The world exploded with options, and the search engines came to help organize (and monetize) it.  By the end of the aughts we have social media, YouTube, and targeted marketing.  And a lot of noise.

The same thing happened in B2B sales, which I got to watch firsthand from my first product job at a lead management and customer relationship company working with large multi-nationals.  It was no longer enough to manage your supply chain, distribution network, and brand reputation.  Now you needed to think with more precision about who you were selling to.  Enter concepts that are still with us today: personas, buyer journey, segmentation, and ideal customer profile.  To be clear, these concepts were always there, unnamed in the dusty corners of pitch rooms.  Companies always have differentiated products into different markets, see also: the different sizes of candy bars or packaging of soap at different retail locations.  But what happened was an acceleration of need for this deep thinking and an explosion of competition.  Not only could big companies have more ways to segment customers, but smaller companies could quickly identify and build into gaps.  Pets.com didn’t survive but targeted marketing sure did.  Just remember that congressional testimony about the Facebook business model from Zuckerberg: “Senator, we run ads”.  User data, micro-targeting, segmentation is a standard operating process now.  You must be a lot more intelligent about your “who” to survive.  Stop smirking Mark.

Enter the Blue Ocean Strategy

Another important aspect of this trend is the impact of the Blue Ocean Strategy and long-tail marketing.  In 2004, Renée Mauborgne and W. Chan Kim publish a book that basically says that instead of competing in the same market everyone else is, the red ocean, find the place where there is an underserved customer base.  I say that out loud and it sounds obvious, but it was anything but in practice.  Remember we are at an age when scale is a major factor in success.  Big companies survive through inertia and small companies can only get so big before they are eaten.  The SMB market is overwhelmingly either hyper local or suppliers to the big boys (like the company I worked for).  A concept we saw deeply tested by the 2001 Enron scandal and shattered in the 2008 lehman brother collapse during the financial crisis.  Big companies fail too sometimes.

When you look at market opportunities, if you look where other companies already are you must spend your time making a value-cost trade off and differentiate on either quality or cost.  This “red ocean thinking” drives the middle out of a market and results in either high cost “specialized” or brand goods or a race to low-cost efficiency.  Luxury handbags are an example of the former, Walmart is an example of the latter.  The classic example of blue ocean strategy for me is the Wii.  When the Wii arrived on the video game market in 2006 it was revolutionary.  With it’s shorter play times and more party game style, it was going after a totally different interaction pattern and market.  It really was a precursor to the phone games that now take up way too much of my screen time.  Standalone gaming systems was already a deeply competitive and saturated market with Playstation and Nintendo sucking up all the air, and occasionally Xbox producing something reasonable (gotta give love to Grand Theft Auto).  By 2006 it was a market that had falling into an arm’s race based purely on computer specs.  But the Wii wasn’t for teenage boys (and girls thank you very much) in their parent’s basements (and dorm rooms).  It was suddenly targeting their parents with memorable, collaborative experiences.  With games that were about getting up and moving, and interacting with people in the same room, it was a totally different concept.  It could include the entire family.  But there were two absolutely genius things the inventors of the Wii understood that it took years for the rest of the market to catch on to:

  1. Parents are the ones with the money, not the kids
  2. Kids becomes adults

Because, fundamentally, they changed the value proposition for a gaming console into a market that really had no competition.  Atari started the market, really, in 1977.  The Nintendo first hit the states in 1985 with Playstation following in 1994 and Xbox in 2001.  By 2006 the Blue Ocean that Atari and Nintendo had discovered had become bloody.  But also, the children (cough me and my brother cough) who begged their parents for those early gaming systems (I still miss my duck hunt) had grown into adults.  Gaming had become mainstream, and with it, what some (read: me but not my brother) wanted from it was evolving.  There was still a market for gaming systems targeting people who wanted to spend hours immersed in a story (teenagers) but there was now an acceptable market for adults who want to casually game.  I will also point out that Wii may have been the first gaming system to understand that half the population is female and we don’t just don’t want “pink it and shrink it”.  That’s the wrong way to do segmentation.  The Wii did it right. Again, same thing happens with B2B it’s just the consumer goods examples are so much easier. 

Wag the Long Tail Marketing

In October 2004, Chris Anderson publishes an article in Wired magazine called “The Long Tail” which he later turned into a book in 2006.  The concept here, again, feels obvious in retrospect but was revolutionary at the time.  If you think about market demand on a chart there is a lot of demand for a few products and then there are a bunch of products with a really niche market demand.  Most companies obey Sutton’s law and go after products where there is the most market demand.  “Why do you rob banks?” “Because that’s where the money is.”  But that means there is a lot of need in those niche markets that are harder to solve.  Enter the internet and catalog management most famously visible with early Amazon.  When they were just a book seller they differentiated themselves by providing a very expansive catalog.  While you could go to any bookstore to find the newest best seller, if you were looking for a niche book you just couldn’t find it without going to a specialized seller.  Enter the internet and not only could those niche book producer start to find their market easier but a company like Amazon could include those niche books in their catalogue without risk.  You don’t have to stock it if no one buys it. 

By 2004 the economic reality Anderson could point to is that sales into those niche markets could outperform the bestsellers with lower competition (blue ocean), higher conversion rates, and better brand loyalty.  There are a lot of other reasons why early Amazon was successful which is probably a different blog post but I’ll drop another here for context: they understood they weren’t selling books.  They were selling trusted access to niche markets.  In the early aughts Amazon was a safe place to give your credit card number to get those specialized items.  Way safer than going to “momandpopbooks.org”.

Long tail marketing is born because of digitalization and better market access.  Sits on top of blue ocean strategy, social media, and segmentation strategy.  It then helps give birth to the influencer which I am, of course, too old to understand.  But all of these factors, together, break the old ways of marketing.  Companies can no longer sell “everything to everybody” and perhaps they never could.  The last decades have seen the end of “everything stores”, also known as department stores, like Sears.  It’s not just the move online but also the ability to easily create niche products, find segmented customers, and compete in markets that were incredibly inefficient to target before, and therefore were left to companies without scale.  So we come to today with all these factors changing the how we go to market and who we target.  Enter Insane Clown Posse… I mean, cough, Ideal Customer Profiles.

Tune in Next time, same Bat-Post, same Bat-Blog

This was going to be one post talking about ICP, modern considerations, how to build it and apply it, and cautions and anti-patterns.  But I was having too much fun with the history, and I think the context is too often glossed over.  So, we will continue with application next time.  And maybe I’ll even try to drop some sick rhymes.

Note: I don’t use AI to help write my posts.  I did use search, and the associated embedded AI that is everywhere, to find the actual dates, links, and references I made throughout this post because I wanted to provide credit where it is due.  I also used Google Gemini to create the header image because I couldn’t resist Glenn2dope Glen Violent J.

It Depends

Posted on Posted in Build Things People WantTagged , , , , Leave a comment

Early in my career, I moved into a new company as the only product leader for the engineering, network, and desktop support teams.  I went from having 2 direct reports to (eventually as I rebuilt the team) 21 and department head responsibilities.  Knowing I was going into a leadership position with a team that had had significant management turnover, I started with some small group and one on one meetings to get a sense of where the team was and what they needed.  In one of these meetings, a senior engineering told me that I was there is “help us build things people want”.  She was tired of building products that went unused and were then deemed a “failure”.  The software was built right, the team was high performing, but the gap between what they were building and what the market was buying was enormous.

Throughout the companies I have worked at, teams I have led, and products I have built “build things people want” has continued to be my clarion call.  It has wormed its way into conference talks and blogs.  It has helped me find clarity in difficult conversations with sales and account teams.  And it has become more nuanced and more complex as the challenges of building products has become more complicated.  Who are the people we are building for?  How do we know what they want?  When do we drive based on instinct and when on user data?  What kinds of experiments help us better answer these questions?  What kind of commercialization is required?  When do we trade-off between speed to market (I want it now) and performance and reliability (I want it dependable)?

Recently, I have found another phase slipping into my mouth more and more: “It Depends”.  I have had to shed the comforting clarity that we are here to “build things people want” for the situational awareness, and yes anxiety, that there isn’t a clear right answer most of the time.  What works with one company, customer base, team, market environment, or existing product and tech debt doesn’t easily translate to another.  It is exciting to realize there is no rulebook but also terrifying that each moment is a rebuilding of the rules.  Some things stay the same but the complexity, as it always was, is in the details. 

As product managers it often feels like we spend a lot of time trying to find repeatable processes and the perfect document.  While these things are valuable, it takes us away from those details and nuances.  Perhaps it is simply my dislike of external structure, but I find myself wanting to explore that space of “it depends” more, while still holding on to that drive to “build things people want”.  Because I do think there are mental models and, yes, structures that can help us navigate the ambiguity.  But also, it’s work worth doing and maybe along the way of my own explorations I can help others untangle these knots.  Also, I have been told by my teams before that they miss my “Jennie-isms” once we re no longer working together. So hopefully a little humor and interesting stories along the way as well.

KCDC 2022 – Build Things People Want

Posted on Posted in Build Things People Want

Super excited to be presenting at KCDC about building things people want. This is one of my favorite topics and it provides a lot of opportunity to dig deeper into topics.

Slides

build-things-people-want-kcdc-2022Download

Blogs on This Topic

Mental Model Minute: A Decision Making Model

Collaboration is good. Making decisions is good. These two things don’t have to be in conflict. I have seen a lot of small but growing companies where this feels like an either/or choice but it doesn’t have to be. The key is knowing who makes the decision and how much input is required. The more explicit we can be…

The Next Right Thing

You’ve seen Frozen 2, right?  I mean, if your household is anything like mine, it’s playing on repeat in the background as children scramble, color, and fight.  Admittedly, I have only sat and watched it end to end once.  Still, there is one part of the movie that stick out to me and, I think,…

Customer Intimacy and Segmentation

The biggest mistake young companies make is trying to sell everything to everyone.  It is impossible to get a clear value proposition or distinct competitive advantage without a targeted market segment.  The biggest mistake older companies make is not realizing when the market has changed and that segment is consolidating, shrinking, or shifting.  Both of…

Formulating Problem Statements

This morning, my children were arguing over spoons.  At breakfast it is my 5-year-old Finley’s job to get out the silverware for herself and her sister.  My Thalia, in the meantime, is just about to turn 3 and is fully feeling her control issues.  Every morning they use these particular baby spoons to eat their…

Build Things People Want

When I started at my current company, the mandate I was given by the developers was to help them build things people want.  It is something I have heard over and over again from developers throughout my career.  And frankly, it’s a goal that the organization and the developers should be aligned on.  The business…

Finding the First Thin Cut

My goal in any product development effort is to get an iteration in front of users as quickly as possible so I can see real users interact with it and respond to their emerging needs. The quicker I can build that first MVP, the sooner the feedback loop of engaging with users can take over.…

Videos on This Topic

Formulating Problem Statements
Hypothesis Testing
Story Mapping
Story Splitting

The Next Right Thing

Posted on Posted in Build Things People Want, Debt

You’ve seen Frozen 2, right?  I mean, if your household is anything like mine, it’s playing on repeat in the background as children scramble, color, and fight.  Admittedly, I have only sat and watched it end to end once.  Still, there is one part of the movie that stick out to me and, I think, has a lot to teach us about business decision making and product management.  Warning, movie spoilers ahead.

After discovering a lot of hard truths about her own grandfather’s culpability in a generations long unnecessary war, and the apparent loss of her sister to the ongoing tragedy (who said children’s movies were lighthearted), Anna is stuck.  She must standup, dust herself off, and determine what to do now.  She sings a hauntingly beautiful song about grief and figuring out how to go on.

I don’t know anymore what is true
I can’t find my direction, I’m all alone
The only star that guided me was you
How to rise from the floor?
But it’s not you I’m rising for
Just do the next right thing
Take a step, step again,
It’s all that I can to do
The next right thing
I won’t look too far ahead
It’s too much for me to take
But break it down to this next breath, this next step
This next choice is one that I can make

The Next Right Thing, Frozen 2

Often I find myself at an impasse.  Maybe it’s not the fate of the world and the righting of generations of wrong sitting on my shoulders, but the pressure does affect me none the less.  Sometimes it is something stupid simple like how a UI interaction should work.  More often it is the juggling of priorities.  My team can only tackle one thing right now, here is the list of problems facing us, what is the next right thing.  And there it is, the song pops into my brain and wiggles itself down into my toes.

These are the moments I take a step back, like Anna, and see what inspiration sticks me.

  • Can I easily summarize the problem?
  • What is the root cause of the problem?
  • Who else can I talk to about this problem?  Do we agree on the same problem, or do they have a different perspective on it?
  • Why do I feel like this is a real problem?  What are the consequences of not addressing this problem?  Who will be affected and how soon if the problem persists?

If you have ever read anything I have written or listened to one of my talks, this will sound like pretty Jennie-standard-faire.  Find the problem statement and the solution will become apparent.

The struggle I have when I train and talk to other product managers how much we want, and sometimes need, a structure for this kind of decision.  Instincts and experience are not scalable.  So, we must find some balance between structure that helps in decision making with the instincts that allow good decisions to be made quickly and with a decent right/wrong percentage.  Over time these tools can become second nature.  Here are a couple of my favorites:

Prioritization Matrix:

Draw a 2 x 2, label one axis with affect measures such as:

  • Urgency: How quickly someone will feel the affect
  • Density: How many people will feel the affect
  • Impact: Significance of the change to the people affected
  • Importance: The importance of the people feeling the affect to your organization

Label the other axis with an effort measure such as:

  • Level of effort: How much effort it will take your team to address it
  • Feasibility: Likelihood the problem is solvable
  • Isolation: Ability to solve the problem without having to solve all other problem (or a measurement of dependencies

Once you have your problems laid out in your matrix you can easily determine which to action on by using this rule of thumb:

Prioritization Matrix

Tell a Story

Find a friend and tell them the story of your problems.  Have them keep track of how many times you bring up the same problem in your narrative of what is happening to your users.  Generally, that is the problem your instincts are telling you that needs to be solved first.

Anna leaned towards the “tell a story” method.  She looked around at her situation and said, “here is what I see going on, here are all the pieces of what I observe.” And from there she was able to figure out the next right thing without getting too focused on what comes after that step.  Sometimes it is that trust in ourselves that we need to be growing.

Customer Intimacy and Segmentation

Posted on Posted in Build Things People Want

The biggest mistake young companies make is trying to sell everything to everyone.  It is impossible to get a clear value proposition or distinct competitive advantage without a targeted market segment.  The biggest mistake older companies make is not realizing when the market has changed and that segment is consolidating, shrinking, or shifting.  Both of these, sometimes fatal, mistakes stem from the same place: not understanding your “who”.

Developers have challenged me over the course of my career as a product owner to help them build things people want.  It’s a deceptively easy demand to make because it is much too easy to assume that if it sells it is valuable.  However, I am not just concerned about today’s profitability.  I am concerned about tomorrow’s customer, scalability, and competitive landscape.  I am not just concerned with today’s customers.  I am concerned with customer retention (stickiness), customer acquisition, and the balance of power within my market.  So how do you understand your “who”?

Start with “who” you know

The best way to understand your unique market segment and positioning is your current customer.  Prospects who look like you already sell to are your strongest potential customers. However, too often when we do this kind of comparison it’s based on demographics.  While demographics can be powerful, they don’t tell the entire story.  Marketing personas are primarily demographics based in my experience.  At three different companies I have worked at, with dramatically different products, value propositions, and markets, they all had the same basic marketing persona: Jennifer.  She’s between 25 and 45.  She works in marketing.  She drinks coffee in the morning.  She has two children and a dog.  She is very busy and doesn’t have time for your messaging.  She is looking for something to simplifier her life.  I feel bad for her, in addition to her full time job, she has to pose for all these marketing documents.

Jennifer is fine.  I have nothing honestly against her.  Demographics are valuable for our marketing and sales teams because that is how marketing spend is targeted.  However, at the end of the day, I am not building marketing messages I am building products.  I want to know what gets under her skin.  I want to know what frustrates her enough that she will give me her money to save her time.  When I am looking at market segments, I am not looking at how to find that customer.  I am looking for the unique set of challenges she is trying to solve. I am looking for problem statements.

So, start by talking to your current clients to build a customer empathy map.  You want to know where your product fits into their lives.  What problems does it solve?  What problems does it create?  What other solutions are they using to solve similar (in their mind) problems?  What does their daily life look like?  Who in their industry do they admire?  What are those people doing differently? 

My favorite technique for building a customer empathy map is a problem interview.  A problem interview is an open inquiry into what a user’s experience is.  When using this technique for building out your market landscape, stay high level instead of diving into specific problems and products.  Essentially, a problem interview is there to give you a framework for a frank conversation.  The format I like to use looks like this:

Introduce yourself and why you are asking questions

  • Introduce yourself
  • Set the stage for the questions you will be asking
  • Make the conversation feel safe

Hi, I’m Jennie.  I am the product owner of this awesome product you currently use.  This means I get to understand what we are doing to help you and how to make things for you even easier.  I am talking to a bunch of our customers right now to better sense of how we fit into their lives.  I appreciate you taking the time to talk with me today.  I may ask some questions that may seem a little off beat and I may ask you to repeat yourself.  This is just because I want to understand fully what you are saying.  This is not a sales call and at no point am I going to ask you purchasing questions. There are no silly answers.

About them

  • Demographics and relationship to the product
  • Goals for using the product

I would like to just start with a sense of your position within your company and how you use our product.  What is your title?  How frequently do you use our product?  How do you measure success?  Who makes the purchasing decision?

Tell me about the last time you …

  • Ask open ended questions about the usage of your product
  • Follow up with “why was that painful?”
  • Stay focused on what they are saying and ask follow up questions specific to their experience

Can you tell me about the last time you used this widget, what were you trying to accomplish?   What went wrong?  What went right?  Why was that painful?  What could have gone better? Tell me more about your experience. Who else used this widget? How else have you solved this problem? What other problems is this solution causing you?

Go through this process with many clients until you start to see patterns.

Build Segments

Based on your customer interviews and customer empathy map, you can start to get a sense of some product-based segments.  These should be based on the problems the users are trying to solve.  Get creative in how you break this down.  You will start to build out a set of customer profiles.  A good customer profile includes the jobs the user is trying to accomplish and what they gains and pains they have from their current experience.

Based on understanding the segments you have built from current customers, you can look at the market at large to see where your product fits in.  You will quickly see adjacent markets based on product appeal at which point you can start to measure and test what it would take to attract those customers.  You can also start to see trends in your market penetration and market drift.  Are you still selling to the same people you have historically?  Is the size of that market segment changing?  Is your appeal to that market segment changing?  Are the problems that market segment is facing changing?  What nearby segments could you start to appeal to by shifting simple things about your product, marketing messaging, or service model?

In other words what you are doing is:

  • Interview your existing customer base
  • Build customer empathy maps for each customer
  • Group customers together based on common problem statements
  • Build customer profiles based on those group
  • Group your entire customer base into those segments
  • Evaluate the market at large based on the segment penetration of the current customer base

RFPs, proposals, market forums, product reviews for competitive products are good sources for understanding the problem statements for non-customers in similar or adjacent markets.  Putting it together, it ends up looking like this:

I have found this approach to be very effective for building out a backlog and product vision within a company with an existing customer base.  Keeping in touch with your customer base as the market changes is essential to keeping a viable product vision and understand where your product is within the product lifecycle.  Not all product opportunities are for an existing market or with an existing company.  In a future post I will talk about how to tackle that challenge.

Build things people want

When building a product, no matter what it is, it is essential to start with the “who”.  Over time, markets change.  Problems change.  The availability of solutions change.  Budgets, purchasing patterns, structures at client organizations change.  Your product is a living solution to problems.  It needs care and feeding.  So does your understanding of the problems the people you are building the product for.

In future posts I will talk more about the “want” part of Build Things People want.  I want to talk about:

  • Hypothesis Testing
  • Product roadmap planning
  • Deciding what not to build
  • Building the product box

Formulating Problem Statements

Posted on Posted in Build Things People Want

This morning, my children were arguing over spoons.  At breakfast it is my 5-year-old Finley’s job to get out the silverware for herself and her sister.  My Thalia, in the meantime, is just about to turn 3 and is fully feeling her control issues.  Every morning they use these particular baby spoons to eat their yogurt.  There are only 4 of them, three blue and one pink.  For some reason they prefer these for yogurt over all other spoons.

This morning, Thalia’s bowl was pink and her cup was pink so she was insisting on having a pink spoon.  However, Finley had already claimed the one pink yogurt spoon for herself.  So Finley was ruthlessly trying to convince her sister to accept a blue yogurt spoon so she didn’t have to give up her pink yogurt spoon to her sister.  After several minutes of back and forth, I intervened.  I opened the silverware drawer to find a wide assortment of spoons in all colors and styles.  I plunked out a blue yogurt spoon, a pink and silver spoon, and a plastic red spoon.  I held the three options up for Thalia to choose from.  She selected the pink spoon.  Breakfast continued in peace and I was left to wonder why we had so many spoons if the girls were just going to argue every morning over one.  (Hint if you aren’t a parent, it wouldn’t matter how many spoons we had, they would still argue.)

I hate to compare clients, or myself, to my children, but that is exactly what I am about to do.

Too often when I am working with users to build a product I find myself slipping into the same tendencies Finley did.  I hear what I want to hear.  I don’t listen closely to understand the actual things that are causing pain or would resolve their problem.  I know something and it guides how I approach the discussion.  Also, if I already have a solution in mind, I will press it even as the user tells me it doesn’t solve their problem.  At the same time, users can be a bit like Thalia.  They can repeatedly tell me the solution they want instead of what their problem is.

This is because humans are fallible.  We are terrible at communicating.  Our mind is constantly working within cognitive biases.  Maybe in a different post I will dig into these cognitive biases, but I will just leave a set of them here so we can use them as a foundation for the rest of this discussion.

Fortunately, for us poor humans who operate barely more dependably than a 5-year-old, there are strategies to overcoming these cognitive biases and effectively define the work to be done using problem statements.  Spending time with user to fully understand their problem statement prevents spending sprint time solving the wrong problem or worsening tech debt.  Problem statements do this by

  • Separating decision making from cognitive biases
  • Establishing a common language
  • Creating a shared user-focused context around the actual problem on which to test solutions
  • Allowing solutions to be more resilient by putting them in the system context instead of the user context
  • Supporting small testable hypotheses
  • Separating the signal of the problem from the noise of the technical system we are operating in

Okay, so you are convinced this is something worth doing.  Compelling problem statements unify users and developers together around a common cause and clarify requirements.  So how do we find the problem statement?

To me, good problem statements look a lot like good user stories and they start from a pretty common place: talking to users.  The key is when you are talking to users to constantly refocus them on describing their process, and what about it is frustrating them, instead of trying to brainstorm solutions.  When interviewing a user think about:

  • What activities or jobs are they trying to complete?
  • What is impeding them from those actions?
  • What workarounds are they using to get around the software’s limitations?
  • Why do they want to accomplish that action?
  • Why do they feel pain with the current process?

All of these are questions of user behavior, not system actions.  If your user starts to tell you how they wished it worked, listen but don’t start to brainstorm solutions.  Don’t forget when you are conducting this interview to watch out for those cognitive biases. Stay open and actively listening for what they are trying to accomplish and why the current software is impeding them.  I will often repeat back to them, “What I hear you saying is X.”  Or “I believe what you are trying to do is Y.”  It’s okay to look dumb.  It’s even better to acknowledge up front that you will ask questions that may seem obvious it’s because you want to fully understand the situation.  You are trying to get to specific, repeatable, user actions.  That will result in knowing an expected, measurable customer behavior.  In some cases, I may even lay out what I am hearing in a customer empathy map format. 

This is an exercise in user discovery but on a micro level.  Practicing this with troubleshooting issues will make it more natural when you are interacting with a feature request.  This can then boil up into customer segmentation or market discovery work.

Now you can formulate a problem statement.  A good format for this is:

  • As a type of user
  • I want to complete a job
  • But limitation I am facing me
  • Because description of the system impeding the user
  • Which makes me feel emotion

Note that the description of system impeding the user will become part of the solution statement later but should not be a complete recommended solution.  It is the beginning of the solution discovery process.  Also, the emotion aspect will help you in prioritization in combination with the criticality of the job the user is trying to complete and the type of user facing the problem.

Let’s try it with Thalia’s spoon problem as an example.

  • As a 2-year-old with control issues
  • I want to eat my yogurt
  • But I don’t have a spoon I like
  • Because I want my spoon to match my plate and cup and Finley has the pink yogurt spoon
  • Which makes me feel emotions, so, so many emotions, because I’m two and everything makes me feel emotions.

If you have a good problem statement you should be able to repeat it back to your user and get agreement that it is the problem that they are facing.  Next, you should be able to take it to your developers and talk through solutions to the problem.  Finally, you should be able to validate a solution against the problem statement.  That’s right, a problem statement is a testable hypothesis.

Congratulations, you are now on your way to writing problem statements like a champ.  Next time, we will talk about ways to validate that hypothesis.

Build Things People Want

Posted on Posted in Build Things People Want, Debt

When I started at my current company, the mandate I was given by the developers was to help them build things people want.  It is something I have heard over and over again from developers throughout my career.  And frankly, it’s a goal that the organization and the developers should be aligned on.  The business wants products that sell.  The thing that most undermines a good development team is when they build something that never gets sold, used, or heard about.  But too often, organizations don’t know how to do that.

I am going to spend this post breaking down the problems with “building things people want” that I have run into.  I will spend future posts talking about strategies on how to address each of those problems.

People – The Problem of Who

There is no product that can meet all the needs of all groups of people.  There are hundreds of different kinds of chocolate bars and candies because they appeal to different people, at different price points, at different times.  Today I want a Hershey’s Kiss, tomorrow I want a Lindt Truffle.  Different products met the needs of different target markets and demographics.  So before you can design your product you have to understand who you are designing it for. 

Too often I have seen this turn into a marketing exercise of creating personas.  And the persona always turns out to be a woman named Jennifer who is between 25 and 45 and likes walks on the beach at sunset.  Personas are great, don’t get me wrong, but I am looking for the problems the persona has that I can solve.  I don’t just need to understand demographics, I need to understand what that group is trying to do, why it isn’t working for them right now, and what I can do to resolve those problems.  As with most things, I want to start with a problem statement.  Then I need to validate the problem statement against real users.  Am I solving a real problem?  Have I gotten the problem statement right or am I making assumptions to fit the product I want to build?

Okay, now I have a ‘who’ but there is another really important question that goes along with that who: how many of those ‘who’s exist?  Am I building a product for one very passionate person?  Do I have a robust market segment?  Is it a segment I have access to and legitimacy with? 

Want? – The Problem of What

Understand the problem statement means I can start to find solutions to help that target market.  Here is the truth, though, no organization is capable of solving every problem.  Too often companies spread themselves too thin.  Just because they find a problem within a target market that they have deep understanding of, access to, and legitimacy with doesn’t mean you have the organizational alignment, focus, and depth to be successful at developing the product, bringing it to market, or supporting it organizationally.

The first set of questions around ‘what’ are questions of product market fit.  These are a natural extension of the ‘who’ questions we asked above.  How many people want this solution?  What is the competitive landscape?  Is the market big enough to justify the cost of entry and product development?  Can I get enough market share to justify the ongoing cost of sales and support?  How are competitors likely to respond?  What kind of unique differentiators can I offer?  How sustainable and unique are those differentiators?  Is my solution better enough than what my potential buyers are using now?  What are the switching costs of buyers?  What market pressures are their such as buyer power and distribution models?

The problem of ‘what’ includes not just what the solution looks like in the initial build and the market, but how this new product fits within your company’s identity.  Does this product fit with your long term vision of who you are as a company?  Will it support or detract from current offerings?  Is it easy to scale with your existing staff?  For example, if you been mostly building web applications and now you are going to build a mobile application, what impact does that have on your organizational vision and alignment? 

Build Things? – The Problem of How

Let’s say you have something to build that you know people want.  Even better than that, it’s something that organizationally fits with who you are.  Congratulations, now you are at the problem of ‘how’.  We are going to build something, we know who it is for and what we want it to do for ourselves, our clients, and the organization.  This is the point where I take off my marketing hat and put on my developer hat. 

The first set of questions I have is how we want to organization the development of the product.  How much effort?  How quickly do we need to get something to market?  How thin can our first cut of the solution be in order to start getting feedback?  What kind of feedback loops can we build into our development process and what customers can we engage in that process?  How will we know when we have something complete enough to release?  How do we plan for multiple iterations?  How do we communicate timelines and expectations to stakeholders that is a proper balance of managing expectations and giving ourselves room to pivot?

The second set of questions I have is how we approach the product technically.  What tech stack are we going to use?  How does this fit into or otherwise enable our overall architectural direction?  What tech debt should we attempt to address during this process?  What unaddressed or unaddressable tech debt do we anticipate facing during this process?  Who are the best people for the technical challenges?  What information do we need about the system do we need before we start?  What is our ubiquitous language?  What competitor examples or market concepts can we use as a foundation?

Build things people want seems like such a simple statement on its face.  However, it generates a lot of very important business questions for me.  In some future posts I will spend some time thinking about different strategies I have used to answer some of those questions.

Finding the First Thin Cut

Posted on Posted in Build Things People Want

My goal in any product development effort is to get an iteration in front of users as quickly as possible so I can see real users interact with it and respond to their emerging needs. The quicker I can build that first MVP, the sooner the feedback loop of engaging with users can take over. Over time, I have developed my own personal theory of product prioritization and backlog building that I will use this space to outline. It has helped me quickly build a product backlog and then apply market validation concepts to find the first MVP.

I have had the benefit to hear from a lot of great teachers on product prioritization. Two concepts, one from agile and one from traditional waterfall, stuck together in my head and said “well, that could be really helpful”. These two ideas are Story Mapping and Kano. From those two methodologies I started to experiment with my real backlog and using problem interviews as a basis, found a great way to build customer empathy into prioritization. This is the result.

This is a long post because I have outlined several different product management theories at a high level. Feel free to skip around if you are already familiar with these theories. See the bottom of this post for more resources on these concepts. I’m going to break these into two major phases: Backlog Building and Prioritization

Backlog Building

Problem Interview

Before you can really start prioritizing a list of features you have to understand the customers pains and gains.  In other words, problem understanding must come before solution prioritization. According to Lean, the goal is to develop customer empathy around their jobs to be done so you can build out a list of products and services that aid them in those jobs.  There are a wide range of methods to do this but its best to start with one of the lowest cost methods: problem interviews.

I really love problem interviews because they provide a great structure to have a conversation with customers focused on them within the framework of a specific problem space.  The goal of a problem interview is to talk through a specific customer job to be done to understand all the pains and gains.  A problem interview should never include suggest a solution, testing out pricing, or making a pitch.  Multiple problem interviews across multiple customer segments are necessary to fully understand a complete problem space. 

An effective problem interview happens in three parts:

  • Setting the stage: Establish the goal of the conversation, determine demographic information and how they measure success.
  • Uncover the problems: Talk through the current situation, identify their pain points, discuss how they are solving the situation today.
  • Wrapping up and next steps: Summarize what was discussed, ask permission to follow up, document results.

The most important thing to remember during a problem interview is your role is to listen and build empathy, not to offer solutions.  After a number of problem interviews you can go through your notes and find commonalities.  These become the basis for defining the products and services you will build.

Story Mapping

Okay, so you understand the customers’ needs now you need to organize it into a coherent set of features. This is where story mapping helps you out. Basically what you do is organize your personas and the jobs to be done you learned about in your problem interviews at the top of a board. Then flesh out the features that address those jobs to be done. Often I will spend some up front time creating a basic backbone of the features that I believe we need. Then I invite the development team and we work jointly to break those features into stories. As a group we will also add features. It looks something like this when it’s all done:

I recommend spending some time with Jeff Patton’s book here to fully build out this but it should feel like any other backlog building exercise, just a lot more visual and explicit. This process will take time and it’s worth it because it will simplify all the decision making you have to make moving forward.

Prioritization

Okay, we have a backlog, now how do we know how to prioritize it? There are a lot of prioritization methods and they generally fall somewhere on a spectrum between statistical analysis and instinct. Regardless of what method you use, it is essential to make your assumption visible. Even purely statistical models have assumptions built in.

I generally prefer an approach that is in the middle of these two extremes called Simplified Kano. To understand how we simplify Kano we first need to understand the Kano model.

Kano

Kano is a method of turning client’s stated pains and gains into statistical data for setting feature priorities.  Like most models of this sort, the first goal is to make the assumptions underlying decision making visible and then apply market and user intimacy to rank priorities.  The process starts by surveying users on a series of features trying to discover two things:

  1. Would you even consider a solution that did not include this?  E.g. it is a must have.
  2. If a solution had this would it amaze and motivate you?  E.g. it is an exciter.

Since Kano is a survey method it relies on statistically significant sampling and carefully phasing of questions to not sway the respondents.  The survey method itself is not a good way to find you customer’s pains or gains or build the backlog.  A process like problem interviews needs to be applied first.

You start by having customers rate different features against these two motivators by having them rate their feelings about having and not having the feature as one of the following:

  • I like it
  • I expect it
  • I am neutral to it
  • I can tolerate it
  • I dislike it

With all that data you can then place the feature into one of five categories:

Categories here that affect prioritization are Must-Have, Performance, and Attractive. Must-Have items should be prioritized first because customers will not look at a solution without them. Performance comes second. These are features that will start to define your key differentiators. Attractive features help with differentiation but not as much as performance features.

Reverse features are interesting, you want to actively avoid these based on survey results. Often, though, I find that both these and the faulty results features require more conversation with customers about those specific features.

You can also use some more advanced statistical analysis to plot out the features including rank ordering, but I will not get into that here.  Our goal today is to understand the model.

Simplifying Kano

Kano is a great if you have a large customer base that actively participates in surveys to provide a statistically significant sample.  I have rarely had the luxury of large enough user base or time for statistical analysis.  Here, Simplified Kano comes to the rescue.  Again, this method can not replace the upfront work of getting out of the building (whether literally or figuratively) and talking to your users.  If anything, this method relies heavily on you, and your organization, building that client intimacy habit.

If you have that client intimacy habit, however, Simplified Kano can prevent overburdening your customers with surveys and requests for interviews. I have occasionally seen engaging with customers tip over into customers feeling they are taking the lead in your product development! Not a good place to be with a customer.

Another weakness of Kano is that it only represents the customer perspective. There is another perspective that can heavily impact prioritization: the developers. Building based solely on what the customer’s want may unintentionally leave out foundational or risk mitigation features customer’s expect but can’t articulate. These are features like compliance with regulations or preventing data hygiene issues that can ruin a business.

So how do you do this?

Invite anyone in your organization that can present the customer perspective into the space where you have your story map laid out on a wall. Give them two sets of colored stickies and ask them to dot vote on which stories would be expected by customers or excite customers. Then do the same thing with your developers with the questions of what stories are foundational or mitigate risk. It is important to ask the customer perspective first. The result looks something like this:

I often find that the client perspective leans towards exciters because it is harder for both clients and the folks in your organization that represent them to focus on the mundane. On the other extreme, the developer perspective tends to lean more heavily to risk mitigation.

At this point it is the Product Manager/Owner’s job to review all those marks and add their own if they feel like anything needs adjustment.

Bringing it Together

Okay, now here is the magic sauce that allows you to find your first thin cut. It’s important to remember a thin cut of a product is to get features in front of users so you can start getting feedback. So in your initial release you should almost never have all the stories associated with a feature. As users start giving you feedback, the stories lower in the stack will change.

Reorganize the cards with marks on them. Any cards with a customer perspective of ‘expected’ plus any developer marks goes to the top of the column. Then any cards with a ‘exciter’ plus developer mark. Then any developer marks and finally the rest of the customer perspective. Why do I lean so heavily on the developer perspective? Because I have always built software in an enterprise environment with significant regulations. A startup or less regulated software would prioritize customer features over risk mitigation.

Then you get to draw a line. This is the time to also talk about how big stories may be so you can get a sense of the level of effort your MVP will require and adjust your line as needed. Depending on the characteristic of your organization and how many votes you give your participants you may end up with really large MVP that will need to be further broken down. The result looks something like this.

Now go forth and build great software!

Resources:

As always, I want to acknowledging others’ work that has inspired my own thinking.

  • Agile Product Owner training through Agile for All by Peter Saddington about a method he called Simplified Kano.
  • Kano as described by the wonderful Folding Burritos Guide to the Kano Model which is not for the weak of heart.
  • Jeff Patton at a DSM Agile conference and his book on a method he calls Story Mapping.
  • Eric Ries’ The Lean Startup gives a good overview of different build customer empathy and test customer segments.
  • O’Reilly Running Lean is also a good resource for learning the basics of lean.
  • A great overview of Problem Interviews, and specifically fending off the intrusion of sales attempts into the problem interview.
  • Customer canvas including pains, gains and jobs to be done from Strategyzer.