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.
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.
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…
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,…
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…
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.
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
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…
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…
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.…
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.
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.
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:
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.
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.
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:
Would you even consider a solution that did not include this? E.g. it is a must have.
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.
I was recently discussing with a colleague the two distinct parts of my job: Engineering Team Manager and Software Product Director. In one half I am responsible for the cohesion of the team, supporting and growing team members, and employee exits. In the other half I am responsible for the cohesion of the product vision, support and growing the product features, and retaining clients.
I see a lot of overlap in the work I do in each half but often these two sets of responsibilities don’t come together in a single position. My colleague suggested that I outline a day in the life in this kind of position and see if it resonates with anyone else. And so this is my attempt to do just that.
8:00 Get situated
Review any emails or Slack messages from yesterday that need responded to. Make a list of to dos or promises in progress. Prep anything needed for meetings for the day
8:30 One-on-one
Talk with a team member about their current work assignment and where they are struggling with some technical skills. We set up a mentorship plan with one of the more senior members of the team. Then we transition to talking about their long term growth plans and check to make sure the current work assignment matches with their development goals.
9:00 Standups
Three teams, three standups, three completely different conversations and engagement styles. One team jokes about upcoming lunch plans and then quickly walks through the board top to bottom. One team stops at the first story and get going on a technical debate on approach before I ask if we can take that to our planning. One team goes member by member and seems a little disengaged. I make a note to circle back on the last time to see what team building we can do.
10:00 Design Meeting in Planning
After setting it aside in standup, the team wants to immediately get into a debate on approach in planning. We pull out the digital white board and I start drawing out what I am hearing them say as the debate continues. Soon everyone on the team is drawing out ideas as well and we are settling into a rhythm of collaborative problem solving. I quickly review the market goals of the product we are developing and remind the team where it fits into our overall architectural goals as the discussion goes off into a debate that is not necessary for the immediate problem. Once we all agree on the approach, we turn it into stories and get into planning for the week.
11:30 Lunch
12:00 Re-situate
Look through any emails and Slack messages that came during planning to make sure that nothing needs my immediate attention. Add things that can wait to my to do list, respond to things that can be dealt with immediately. Fortunately, not very much needs urgent attention so I look down my list and calendar to find the next most valuable work.
12:30 Roadmap Presentation Prep
Given the relative quiet of the day, I find some focus time to work on the roadmap presentation I am recording later this week for clients. Put together screenshots of recently released features and outline how I want to describe what is coming next in our products. Review the project plans on the current products against our actual sprint work to ensure I will not be making promises we can’t deliver on. Send an update to the Exec sponsor of one of the products to tell them we are releasing a feature soon they will be especially interested in.
2:00 Open Office Hours
Open my Slack channel for Ask an Engineer and wait for a client facing support staff to ask a question. I quickly end up explaining how the object relationships of some data are impacted the way the information is showing up on the page to one person. Then I get into a discussion of our roll out of a new feature to clients with another.
3:00 Respond to Client Issue
Out of Open Office Hours I have one take away to work through a client issue with the development team. A client has expressed concern with how one of the products is working. I work through the client concern with the team and draft a message back to the client explaining our solution to the concern.
3:30 Huddle on a Proposal
The Sales Director has a prospect with a unique use case for one of our products we wants to talk through with me. We review the prospects needs and the different ways we can use our product to solve it. We come up with a good solution that won’t require any custom development and should work for their budget. I message a member of the client support team I worked with during open office hours to see if we can use one of their clients as an example.
4:00 Review Market Research
With the goal of finishing a draft of my client roadmap presentation, I review the market research for one of the products I want to talk about to ensure the development plan we have in place is supported by our understanding of the market needs. I listen through a problem interview I had recently with a client on that topic and pull out some phases they use for the notes on my slides.
5:00 Close out the Day
I take a moment after saving my presentation to look through my promises in progress list and check off what got done. Then make a note for the next day to think about ways to increase engagement in standups for team three. Close my book, and leave.
Jennie Ocken 