Author: jenoak

Build Things People Want

Posted on Posted in Build Things People Want, Debt

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

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

People – The Problem of Who

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

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

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

Want? – The Problem of What

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

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

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

Build Things? – The Problem of How

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

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

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

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

Finding the First Thin Cut

Posted on Posted in Build Things People Want

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

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

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

Backlog Building

Problem Interview

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

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

An effective problem interview happens in three parts:

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

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

Story Mapping

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

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

Prioritization

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

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

Kano

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

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

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

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

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

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

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

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

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

Simplifying Kano

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

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

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

So how do you do this?

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

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

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

Bringing it Together

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

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

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

Now go forth and build great software!

Resources:

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

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

A Day in the Life

Posted on Posted in Uncategorized

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.

True Confessions of a Product Manager: Project-itis

Posted on Posted in Debt

I have fallen into the trap. It’s such a pretty trap lined with certainty and speaking to underlying control issues. But it is still a trap.

I have, I admit it, gotten stuck in Project Thinking. This is my confession and promise to be better. This is not me entering into the great “No Estimates” debate. There are no winners there. This is a promise to recognize when I am working on a project and when I am working on a product.

What’s the difference?

A product is:

A living application that is defined by engaged and potential customers, their pains and gains, and the contributions to the business. A product’s development should be driven by a long term vision that is outlined in a roadmap with room for iteration and learning.

A project is:

A timeline driven goal to deliver a feature or set of features usually defined in a statement of work or contract at the beginning of the project. A project is successful if it is completed on time and on budget while satisfying the requirements.

If is too easy, when putting together a roadmap, to fall into project thinking. The business and clients want to know not only what new features a product will have but when they will get to be able to use them. Answering those two questions results in a natural impulse to put together a project plan. An impulse that must be controlled, but not eliminated! These questions need to be answered, but they need to include the context of the overall product vision and user feedback loop.

There are two articles that have contributed greatly the way I think about the way I see my responsibilities as product manager: Kyle Evan’s article Product Thinking vs Project Thinking for the Product Coalition and Sriam Narayan’s Products Over Projects on the excellent Martin Fowler blog. I was exposed to both of these blogs by an excellent software developer on my team to whom I will forever be grateful.

I saw that I was not seeing the product through the project, much like the not seeing the forest for the trees. In the building of the product roadmap, all I can see is the forest. However, in implementing features suddenly all I was seeing was trees. Everything about finishing a feature on time and the overall goals of the product were getting lost. This is Project-itis. This is where good product development teams become feature factories.

How to cure project-itis?

After spending some time reading through these articles and looking at my own ways of talking about our product, I realized the key was to know when we are talking about forests and when we are talking about trees. Because the forest is full of trees.

Yes, I know I am overusing that metaphor.

Maybe a visual will help.

A product is a set of features. The way that a product fits together consistently is two things:

  1. A long term product vision that is selective about which features to include.
  2. Room for tech debt, architectural improvements, honoring the campsite rule, and dev ops

The second of these is a subject for a different post.

Once I have a set of product features that support the long term product vision, I can prioritize them. Based on building an effective user feedback loop and product vision, I know which features need to be done quickly, which need more feedback, and what research.

When I open up a feature for the team that is the project. That is where good project life cycle management comes including ideation, market validation, solution generation, and release. This is where finding small slices to get feedback from users come in. This is where a project plan and estimates are useful. Focusing in tight on just that feature is a project.

If all we do is focus on the project, however, the product suffers. The trees don’t talk to each other, don’t work together, and there can be no forest.

Okay, so I really like that metaphor. It’s helping me climb out of the trap though, one tree at a time.