Capturing Customer Insights for Your Squad

Not everyone from the squad (design, engineering, QA) may be there when you talk to customers. So how do capture insights to share what you learned with them?

My vote is the Job Story and I feel this article does a great job explaining it.  A Job Story summarizes key insights way better than an audio recording or written notes.

Let’s write an example job story from my experience in FinTech: planning for retirement.

When I start a new job, I want guidance in selecting my 401k contribution rate, so that I can feel confident about my decision, finish my HR paperwork and get to work! 

Let’s look at each clause in further detail.

The When Clause

This is perhaps the most critical part – it provides important information about the context in which the person is trying to do a job. Some key questions to ask when writing this:

  • What’s prompted the person to think about doing this job? (In the CREATE framework I wrote about previously, this is the cue). In this example the cue was probably filling out some HR paperwork.
  • Where is the person when the cue occurs? As you might imagine things like whether this person is at home, at work, or on the road would be important. Do they have a computer nearby? Or just a phone?

In the example above, if I had just talked to a new hire about their journey to make this decision, I might refine my when clause:

When I’m sitting in my first day HR orientation and am asked to fill out paperwork about how much I want to contribute to my 401k…

The I Want Clause

This is where you explain the job to be done. In this case, it’s deciding how much to save for retirement. Note that I intentionally didn’t specify a solution – no mention that we should show something like “you’d have $50,000 per year if you saved 5% and $70,000 per year if you saved 7%” or “to max out your employer match you should contribute 6%”.  I’m not saying you can’t suggest solutions when reviewing the story with your squad, but I’m a big believer that product managers should be presenting problems, not solutions.

In this example, as the squad starts brainstorming possible solutions, they may come up with either a tool to explore the implications of different contribution rates or an engine that just spits out a recommendation with an explanation. Both solutions might work for the person.

The So That Clause

This is where you explain why it’s important to the person to complete this job.

In this example, it’s important to note that for this person, they want to make a good decision but the real goal is to get through the paperwork and start the role she was hired to do. There might have been other reasons the person wanted to do that job:

…So that I can retire as soon as possible (he doesn’t like working!)

…So that I can minimize my annual tax bill (trying to lower her take home income)

Think about how different the squad might interpret the story based on the way it’s written.

Don’t forget the emotional and social aspects

Every job story has 3 components:

  1. Functional
  2. Emotional
  3. Social

I’ve only written about the functional here to start: what is the person trying to do? It’s important to consider the other two aspects though.

Emotional. How does the person feel before, during, and after they’re doing this job in their life? In this example, we know that doubt is a prominent feeling when retirement planning; no one is really sure when planning for something that might feel so far away.

Social. Will others know that the person has done this job? Will they discuss it openly? What will others think about the person based on how they did this job? In this example, we know it’s not common to discuss your 401k contribution rate with others. Maybe part of the solution is to make it easy to share your contribution decision anonymously within the company or to publish anonymous data from HR so new hires know what others have done in the past.

Want to talk more about how your team is collecting, documenting and using customer insights? Drop me a line. 

4 Tips for Picking KPIs to Measure Your Product’s Success

new_kia_car_financing

Of all the items on a new car sticker, which ones should matter most to the car’s product manager?

Product managers, how do you know if you’re doing a good job?  Your manager tells you so? A customer leaves a glowing product review? Your coworker likes the new feature you launched?  Nope. You’ll know if you’re doing a good job if your product is successful.

But what does success means? It depends on your product, but no matter what, if you don’t have a way to measure success, you’ll never know, and neither will your stakeholders – internal or external.  Here are some tips on choosing Key Performance Indicators to measure the success of your product.

Tip 1: Start With the Money

I’ve written about this before: the ultimate measure of success should be a business outcome, so you should have at least one KPI that has a dollar sign in front of it.  Profitability is ideal, but revenue or cost savings for your company are also good.  If you need a shorter feedback loop on a KPI like revenue (because your sales cycle is really long), use a proxy KPI (for example, maybe you know that your sales team closes 80% of deals after 2 meetings with the decision maker – great, use that instead of revenue).

 

Tip 2: The Customer KPI

At least one KPI (not revenue) should be one that you share with customers and that measures the outcomes they’re trying to achieve through your product.  It might be time or cost savings, or weight loss if you’re building a health app.  Don’t be shy to get creative with this one – maybe you derive a new formula that combines cost savings, time savings and weight loss if all 3 are key outcomes your customers are seeking.  Having this customer KPI focuses the team on delivering value regularly, and helps you avoid awkward “I don’t know what I’m paying for” conversations when you ask customers to extend their term with you.

Tip 3: Don’t Pick Too Many KPIs

At most, I’d suggest 2 or 3.  Why? Because if you’re prioritizing changes (or tests) to improve your KPIs, it’s hard to juggle too many.  Don’t forget about the “K” in KPI.  In an ideal world,  you might even assign a KPI to each of your product owners and development squads, so that they know whether their work is resulting in meaningful business value.

Tip 4: Measure Often

KPIs don’t matter if you can’t measure them easily, especially if you’re releasing frequently as a part of an Agile process.  Make sure you can measure your KPIs within a few minutes, and that the data needed to measure them is updated often – at least daily.  If you need to prioritize time to instrument your product to make measurement easier, do it.  Otherwise you’re either flying blind, or there’s too much of a delay in your feedback loop.  Also, don’t forget to publish your KPIs regularly for internal stakeholders, so that they can also see how your product is doing.

 

Want to discuss your KPIs?