I am a Unicorn (and other insights from community building)

This is not (necessarily) work related.

This is my daughter, Finley. Yesterday at school she learned how to sign “I am a unicorn” (gif link). I consider this an important life skill.

She regularly comes home and tells me about the various new signs she has learned like “exuberant” (one of her favorites). Finley does not have any hearing or speech impairments. Her Kindergarten teacher is using American Sign Language (ASL) and Spanish as tools for teaching reading and writing. She has a friend Felicity (the daughter a dear friend) who lost her hearing and recently got a cochlear implant. While the other kids teased Felicity, Finley showed curiosity and compassion. She has told us that when she grows up, she wants to be “a voter” and wants to live with “deaf people because they can teach me so much”. I am indescribably proud of her. But this doesn’t happen by accident.

My uncle Ron taught me ASL for the alphabet, numbers to 10, relationships (mother, father, etc), basic courtesy, and some animals that would interest a 9-year-old. It was survival level ASL and a gift that he gave to as many of his nephews and nieces. It was also a glimpse into a world that most people don’t know exists. Ron was born blind and deaf because of a congenital condition that also impacted my sister to an extreme degree. He would teach ASL by moving your hands into the correct shapes. I learned the nuanced differences between F and 9 that a sighted practitioner of ASL wouldn’t care about (even within the deaf community, there are subcommunities). He also taught braille at the Iowa School for the Blind and was a professional computer programmer. I also learned recently that he was a well-respected advocate for disability rights (Ron referred to himself as disabled. He hated the recent trend towards “differently abled” because, in his words, “being blind isn’t an ability”). He built communities everywhere he went in his life. Through him I learned about nuanced parts of the deaf community that a hearing person would never interact with.

I have always talked to my children about my uncle and my sister and the things they experienced. I can see in the three generations how much the world has changed. Ron struggled and fought for understanding and support for his whole life. I was ambidextrous leaning towards left-handed as a kid, the teachers wouldn’t let me write with my left hand. Finely is learning ASL in Kindergarten and her teacher protect and encourage her left-handedness. The world has evolved. Slowly and in ways sometimes too small to see. But at least now my child knows how to say “I am a unicorn” in multiple languages.

This part is work related.

I think my new hero is Frances Haugen (who also is an Iowan, btw). What she has done, the bravery it displays, is breathtaking. She talks about the possibility for social media that brings out the best in humanity. Recently, every time I have written a document I have thought “how would I feel if someone like Frances was looking at this?” This has been especially true as I have been trying to get clarity around our data capture and tracking policy. Because I want what we do here to be for the general good. Because I believe that there is a need for people to build communities. And that should happen in a way that isn’t creepy and isn’t just trying to manipulate people. I am equally motivated in my work by a consciousness of how understanding different cultures and life experiences makes us less cruel and more compassionate towards each other. And by my 6-year-old who is being exposed to those differences in a way that makes her curious instead of afraid. How different her world is, already, from the one my uncle was born into.

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 about who makes a decision, the better we are going to be at actually making the decisions.

To that end, I have started using a really lightweight framework for this and wanted to share that here. I am going to get more diligent about this personally. In meetings, documents, and other decision making spaces I am going to put out this little block. Example from a recent meeting:

EPIC: Better Sidebar/Links Organization
RFC(s): None currently
Priority: Very High (1c)
Meeting type: Discovery

Description: Allow Creator to have better control over the left bar with some options including:

  • More granular organizational structure / more sections than just “other”
  • Specify the open on site vs open in new tab options
  • Dominance of iconography / style

Stakeholder Roles:
Decision Owner: Jennie for this meeting, PM moving forward
Consult/Advise: CEO, Designer, Engineering team
Inform: Client

During the meeting, I will verbally note the things we are trying to decide and, if appropriate, what the decision was. After the meeting, I will document the decisions made at the meeting and any logic for that decision. This is especially important in our async environment. The idea here, though, is to make decisions quickly without a lot of process and clearly. I am sure we will iterate on this over time.

Mental Model Minute: Intent Based Leadership

I have so many things to share with you but so many discussions I have been having keep leading me back to this Mental Model Moment I thought I would share. And it’s easy, because it’s the author and this great illustrator do so much of the work for me. On the other side I can share my take aways and how I have implemented this with teams before.

Start with Clarity

Intent based leadership is all about setting the distant island we are trying to reach via the ship, and then collaborating as a team for the best way to get there. Teams are formed with different skill sets and the ability to have hard conversations around both priorities and implementation.

I had one team that was building a Form Builder. This was a priority for the company because of some compliance issues with our existing solution (PCI security) and a potential untapped market. So for that team we had two clear goals:

  1. Migrate existing users off the existing solution
  2. Prepare a product for go to market

Every meeting we had, every planning, every time we discussed a feature, we asked if it met those two goals. To the point that my otherwise quiet UI/UX developer (the Sheriff) would interrupt me outlining a feature to say, “This doesn’t seem in line with our goals, why are we doing it?”

In other words, the team started to understand “Is it the right thing to do”.

Build Structures around Competence

Over time the “is it safe” questions become engrained in the conversation. Each time I work with a team on whether we would release something I would ask the same questions. To the point were one of my developers started to impersonate me. “Will it break production? Have we informed the users? Do we have documentation?” Questions like that. This, as well, becomes a pattern of how the team acts.

At my last gig, we had a system that was forklifted from a mainframe with no test environment. As a result, questions of release, between my delivery lead and myself, were always about how much certainty can we have that none of us will be working the weekend. Followed directly by questions of where are the opportunities to create unit tests, or small test environments around sections of the application even if end-to-end tests can’t be done.

Moral and Ethical Responsibility

As a leader, there will always be some tasks you must reserve for yourself because it is irresponsible to allow that to be a team decision. The key here is to be explicit (using those 7 levels of delegation perhaps) on when that is happening.

When I was a department head I reserved two things:
1) Starting the firing process with HR
2) Telling a customer “no”

Neither of those things where my team should have carried that burden. I explicitly told them this. My tech leads would reserve some very specific breaking technical changes. For example, only the tech lead of my dev/ops team could take our CI/CD system completely offline.

Mental Model Minute: Seven Levels of Authority

We are all growing and learning as professionals in a collaborative workspace. It can be helpful to take a step back and look at different models of individual and team behavior. A “mental model minute” takes just a moment to describe a different view on how to perform or interact better that we can react to and learn from. I will post these from time to time. If you know of mental models that have helped you, post!

One of the hardest things to navigate in a collaborative workplace is whose decision something is. This is where the “Seven Levels of Authority” from Management 3.0 by Jugen Appelo model comes in handy. His model is about authority definitions between a manager and their team. I have found it useful between individuals or across teams as long as you clearly define who is playing each role.

The Model

Too often in decision making we think it’s “your decision” or “my decision”. However, actual decision-making authority is way more nuanced than that.

Seven Levels of Authority

At one end of the model, the decision is 100% “mine”. E.g. as the manager, I am telling you what we are doing. I have most often seen this level arise (in healthy organizations) in situations where information is highly protected such as a firing decision or where risk is high such as PCI compliance.

On the other end, the decision is 100% “yours”. E.g. as the team, the manager has delegated the decision and has no need to be further involved. I have most often seen this in implementation details or technical details from a non-technical manager/product owner.

In the middle of the model is “Agree”. In other words, the decision is made jointly between the parties. The biggest risk with “agree” decisions is they don’t ever actually get made. To mitigate that it is helpful to put an artificial process like dot voting or a timebox in place.

Most decisions fall on one side of this or the other.

With “Sell” and “Inquire” the decision is made by one party but the other party wants to be informed after the fact. With “Consult” and “Advise” the decision is made by party with the other party giving input before the decision is made. In all these cases, a party has the clear decision-making authority. For example, in “Consult” the decision is made by manager with input from the team beforehand. An example of this may be hiring decisions. With “Advise” decision it is often important for the manager role to publicly support the decision after the fact for the team to feel like they are actually allowed to make the decision until norms are established.

How to Use it

The other night, my husband’s phone died. He went out and bought a new one. I asked him how much he spent on it, and he deflected the question. I got angry at him and he was upset with me. Why? We had talked about how a phone is critical for both his home and work life. Whereas I can run with something barely functioning for a surprisingly long time, he spends 80% of his work time on the phone. His phone had ceased to function as a phone. We had talked about how it was urgent he get the phone replaced. We even agreed I would single parent bedtime so he could get to the store before it closed. So why was I upset? Because it was not a simple “his decision”. In this case, think of me as the manager (yay marriage). He thought this was a level 7. I had fully delegated the decision to him. I thought it was a 5 or 6. I wanted to hear about the decision after the fact and the details. In a 20-year relationship, we can be dialed into the difference between a 6 and a 7. In most work situations that level of detail isn’t necessary. But knowing where that difference in expectation arises allows you to adjust for the next time.

In my last gig, I had a business partner who was going to use the app my team was developing. We would have discussions about the requirements of how the application would make her life better. At various points when trying to decide how something was going to work, I would be very up front with her about who got to make that decision. “That is a technical implementation decision. So I can go talk to the team about options, but we may be limited here” when we were more at the 5/6 area. When we are more at a 2/3 I would say “We can make that happen for you. Here are the trade offs but it is ultimately your decision as the user.” It helped give her clarity on where we were in the project and what the outcomes would be.

I have a friend who uses this technique at work. When she is describing a course of action she is planning on going down, she will end it with “but my boss can always tell me I have other priorities or to do it differently”. Her boss is always in the room in these situations.

KCDC Conference 2021 – Consuming Endangered Pachyderms

Slides

Blogs on related topics

Mental Model Minute: Seven Levels of Authority

We are all growing and learning as professionals in a collaborative workspace. It can be helpful to take a step back and look at different models of individual and team behavior. A “mental model minute” takes just a moment to describe a different view on how to perform or interact better that we can react…

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,…

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…

Also check out other presentations.

That Conference – Build Things People Want

This week I am presenting at That Conference on Feedback Loops and building things people want. Wanted to roll up a few resources and point out some more topics for people interested in this topic.

Slides


Blogs on this Topic

ICP Explainer pt 2: Build Their Dreams

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…

ICP explainer: Segment the World!

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…

It Depends

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…

KCDC 2022 – 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 Blogs on This Topic Videos on This Topic

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…

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

More Videos on my Presentations Page

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, 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.

Remote Work is Here to Stay

As operations leaders across the world stumble and struggle to figure out their “return to work” strategies, I have been reflecting on the nature of the fundamentally collaborative work we do in software development and what it will look like in this new world.  I don’t know what the post-Covid world of work will look like.  But I do know that it will be different and leaders who just try to rest to how things were a year ago are going to be in shock as their employees chose to move to more flexible companies.  So, what do we need to think about as we balance collaboration with employee desire?

Remote work is a benefit, revoking it will have consequences.

While most companies didn’t move into remote work a year plus ago because they were trying to add an employee benefit, that is, in fact, what they did.  Now that employees have gotten an opportunity to work remotely, and for the most part successfully, many will view any change to the remote work policy as the removal of a benefit.  In a lot of workplaces, the right to work remotely was previously reserved for special situations where an employee may want to move across country and the employer desperately wanted to retain that employee.  Now you have the same situation but in reverse.  Employees that choice to make a blanket policy that requires all employees to return to the office, even if only a few days a week, will see turn over.  The presentation of how this return to the office is conducted, and how much agency the employees have in their return, will also affect retention.  As part of your plan, consider retention goals along side other goals like productivity, collaboration, and team unity.  Figure out what you want to measure and what your most important goals are.  For some employees, the ability for managers to be able to work with their staff in person may be a worthwhile tradeoff for significant turn over.  However, just as furloughs, pay reductions, or other benefit reductions will result in employee exits, the same will happen here.  Also remember that the employees that leave first are most often the most talented as they can most easily find other work.

Employee opinions matter

Along that same line, asking employees what they want should be part of your policy strategy.  Rolling out a new return to work policy without conducting a visible employee feedback process will result in lash back, no matter if the employees agree with the ultimate policy or not.  Especially coming at the end of a year where everyone has lost a sense of control in their own life, most people will not take kindly to being told what they will do instead of being consulted in their own destiny.

Also consider that each employee has different goals, work/life balance needs, and work styles that will contribute to their optimal workplace environment.  There is no one size fits all approach.  Policies that declare a certain job family or group of people based on location of their homes will be required to work in the office while giving blanket approval to continue remote work for another group will be seen as unfair or ill considered.  Yes, it is much easier to make policies that apply across the board.  However, leaving room for manager discretion, especially for high performing individuals, is essential.  This isn’t just a matter of retention; it is also a matter of inclusion and diversity.  Different people work, process information, have interactions in different ways.  There differences between people is part of what allows serendipity to happen, not just being in the same place at the same time.  Honor those differences by honoring individual needs.

Identify tradeoffs based on work style and actively mitigate

There are pros and cons to each interaction style.  Fully remote individuals need to work hard to collaborate and consciously build relationships that may naturally develop by bumping into someone at the watercooler.  In office individuals can find it harder to concentrate or to find quiet to work in and be easily distracted by the talk around the watercooler.  Everyone needs to find ways to balance between time at work and time at home regardless of if they are physically in the office or not.  It is overly simplistic to say that people in the office have better connections to their coworkers or people who work remotely focus better.  Everything takes work and it is up to both the individuals and the organization to help employees perform their best regardless of where they work.  Collaboration tools and video helps remote employees feel more engaged.  Sound buffeting and focused spaces help in office employees feel like they can get “heads down time”.

In addition, hiring a remote workforce allows you access to a larger pool of candidates, no matter where your office may be located.

Remote friendly is now the standard

Regardless of your return to the office plan, more likely than not you will now have employees who will remain full time remote.  There was a general trend towards remote friendliness before Covid and now, as with all things in the last year, that trend has accelerated.  This means that a remote friendly office is no longer an option.  You must put cameras in your conference rooms, include collaboration tools in your budget, and be prepared to help manager navigate productivity discussions with employees they can’t see typing on their computers.  However, remote friendliness is more than just how you make sure your remote team members can be part of conversations.  It is also making sure all employees, regardless of where they work, feel like they are part of the team.  Time has to be taken to think about these things.

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 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

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.