How do awesome products come about?

22 Feb 2017

Untitled

Getting to what customers want, not what they think they want, is key to the success of a product manager and consequently to the success of the product itself.

Product managers are usually bombarded with ideas for new features, improvements on features, bugs and often a direct ask from a customer. Whether these requests can be directly built into the product or need deeper research often depend on the lifecycle of the product. A great PM separates herself from mediocre ones by digging into customer conversations to find a bigger, better more value story for the customer and consequently for the product. A recent presentation that I saw used the model T image here is quite instructive and as a PM you don’t want to be trapped with a horse when your customer wants a car.

Horse before car (credit Wikimedia)

Here are some tips that great product managers use to nail customer research:

  • Go through support tickets: Support tickets are like being in an ER room, there is a level of urgent response that is required all the time. That said, a great PM discerns and finds the pattern in the issues and brings it into the product backlog vs jumping heroically on every issue. Support engineers are the heroes in the picture and there isn’t a need for another one. Remember Batman succeeds because Alfred exists.
  • Listen, listen and listen to the field: Your field (customer success, sales engineering, support) are direct lines to your customers. Listen to what they are saying. A good metaphor, is to think of the field as weather sensors and it is your job to discern the weather patterns over a region. The challenge often is that given the time/budget constraints, you won’t be able to build rain shelters in all the places (it is raining heavily in San Jose as I write this) and setting relevant expectations goes a long way. The advantage of getting the feedback from the field is that issues have been condensed and up-leveled to keep urgency away and focus on importance. Great PMs focus on getting to the problem and have discipline to ignore the solution that comes from field in some cases. A PM may get to the same solution but directly consuming a solution from the field or customer is laziness.
  • Get on customer calls with field: Be a fly on the wall and don’t actively participate on customer calls.
    • Don’t taint a customer call: By bringing in privileged knowledge that the field doesn’t have. Great PMs have to empathise with customers and understand the challenges that field faces
    • Actively propose product hypothesis to customers: Be active on some calls, you do need to push a product investment hypothesis to validate with customers.
    • It is hard choosing between the above two modes. So you decide upfront before you get on the call – know if you are a fly or going to pitch on the call. Know what’s what and notify your field counterpart accordingly before you get on the call.
  • Do customer visits: This is really the nub of getting feedback. I wrote a number of blogs about this aspect, so summarising here:
    • Be an intern: when you get to customers, tell them that you are an intern and let them walk you through how they deal with your product or problems in your domain.
    • Stop showing off: Do not offer any advice or show how they can solve the problem with the product before they have gone through the litany of issues. Hear through all the use cases and problems.
    • Pitch product at the tail end of the interview: it shouldn’t be all take, there is some give too :-). Pitch product if it truly solves the problem that they raised in the interview
    • Validate hypothesis: pitch what’s on your roadmap to validate if they will find value in what you build
    • Use power questions: “What’s on your mind” to begin interviews and “What else is on your mind” to end interviews. These do a really good job of exhausting the problem space that you can solve for. “Tell me more” is another great tip to get into details of a problem domain from customers.
    • Summarise: Finally, summarise the visits in internal wikis, share with other product managers and engineers. A customer visit should be used to expand understanding of a domain with everyone in the company.

Improvements in product or life, don’t happen magically or are solved magic bullets. Process changes and focusing on implementing processes is what brings success long term. Incorporate the above ideas in your customer research process and you will build great products.

What really is on your customers mind?

04 Feb 2017

Untitled

Recently I wrote 2 blogs (tell me more, be an intern) talking about tips to conduct an effective customer/prospect interview for product managers. This blog wraps up the tail end of that series.

One of the most effective power questions is “What else is on your mind”. I picked this one up from the Coaching Habit by Michael Stanier. In the book, Michael calls it the mother-of-all-power-questions (ok, you got me, I am exaggerating :-)). I often employ it with my team on the front end of a conversation to land at the key issue that is troubling them and can attest to its efficacy.

Flip the order of the question and ask it at the tail end of an interview.

The customer by this time has gone through his laundry list of “urgent” issues with you and peppered you with a few good important problems.

They are spent – or are they? Hmm…

Now the customer has to dig really deep and this thinking often brings out key problems that may not be very obvious. These problems are usually the ones that you want to solve as product manager or at least help the product manager understand the customer.

Mind-meld – did you say?

A recent example from an interview:

We were recently at a customer and found that they spent substantial amount of time build reports to understand their Amazon costs. The entire hour and a half that we spent there, this didn’t come up – after all they were talking about their Jenkins delivery pipelines. Even they were surprised to realise that the problem was more important to them than they originally thought.

Finally, a customer conversation cannot be rated highly if the product manager hasn’t documented the interview, shared and discussed it with the team, had a couple of compelling deep dive conversations with the customer again.

Be greedy with your customer

20 Jan 2017

Untitled

Finding the right problem, its details, from customer interviews are similar to finding an address in India.

A problem while looking for an address in India is that neighbourhoods are congested and the roads are not labeled. One uses landmarks to reach to the right area, find a shopkeeper to guide you to the next smaller neighbourhood landmark – rinse, repeat – recursion :-).

Similarly, customer interviews are an open-ended discovery process, you hope to find the right problem neighbourhood and then navigate the alley to find the right house. The “be an intern” phase gets you in the right neighbourhood. Getting to the right house means that the product manager wants to

  • gain a deeper understanding of the problem
  • validate earlier assumptions about the problem
  • validate if the solution hypothesis holds up in light of the new information

Tell me more or I would like to know more about…” is a power question that helps clarify and validate assumptions about the problem domain. This question is usually asked after you have poked around the obvious questions on what the customer has told you. In the initial discovery phases this can be used to narrow down the persona as in “tell me more about who has this problem” or understand the depth of the pain as in “tell me more about why this is so important to you”. In the latter phases, when you have prototypes or mockups, the question ends up validating your solution as in “tell me more if you care about this view” or “tell me more if you care about storing logs” or “tell me more about someone who does this well”.

Simple enough! Its power lies in its simplicity. Try it next time.

– Harpreet

 

Tip to conduct great customer interviews – Be an intern

16 Jan 2017

Untitled
Last week, I visited a CloudBees customer with Kohsuke Kawaguchi (Jenkins’ founder) to interview them. The goal was to understand their key challenges and concerns.

Over the years, Kohsuke and myself have done innumerable customer interviews together and somewhere along the way we have hit on a formula that makes for great customer interviews.

The formula is “Be an intern” (credit: as is usually the case with Kohsuke, belongs to him).

An advantage of tag-teaming is that one person takes copious notes while the other asks questions. The interview goes something like this (replace “software delivery process” by the key problem(s) your product solves):

The Interview

Us: Think of us as new interns on your team, now walk us through the entire software delivery process.

Customer: We were using your software and ran into so and so bug with your software.

Us: Hold on. We will definitely get to that. Right now, tell us why that is important as an intern. If not, lets go through your software delivery process

Customer: Uh ok, I guess it is not important as an intern. Ok – so we have a very typical software delivery cycle. We push the code and then we do a “official build” which is then tagged by QE as golden build.

US: Hold on – who is “we” – is this one team or many? What do you mean “typical” – is that in your group, across teams or standardised across your company”. What’s an official build – who calls it official? What does a golden build mean? Who is impacted with golden build? How long the process take?

And so on. You get the idea. The interview becomes very open ended and helps us be part of their team.

Advantages of this approach:

  • No ask-the-experts: Customer interviews are a critical learning process. When product (and in this case the founder of Jenkins) lands up at customers, customers want to jump at the opportunity to make the session as an “ask the experts” session. The intern approach avoids an “ask the expert session”
    • Deep learning of the problems: A distinct shift happens in the customer where they stop viewing you as the expert and start explaining how things should work. As a PM – this is where the key learning for the product happens.
    • Listening to the customer: When you are not the expert, you have no option but to listen – which is a tremendous skill to have as a PM. Listening to the customer is where you learn about the customer and importantly the customer feels heard before you tell them any solution.
    • Validation of the roadmap: The session becomes a “no pitch” session and product management mentally maps problem to the planned roadmap. The usual risk is that product management “shows up and throws up” while the customer sits with folded hands thinking if they should renew or not next year. When you hear the problems and can map to the roadmap, it is a huge validation (or not) to whats planned.
    • Explaining your solution/roadmap after listening to the customer: Once you have validated (or not) the roadmap, have heard the breadth and depth of customer challenges as part of this interview process, you lay out your roadmap and how your solution(or roadmap) helps address the key concerns that were raised in the interview.

If you are a product manager, I encourage you to use this as part of your quiver when you meet customers.

  • Harpreet Singh