guest blogger product management

Driving Product Growth with Customer Interviews in 20 days

Guest Post by: Jeffrey Owens (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Chris Butler]

customersRESIZEDXXX-56ef5043[1]

In the startup mindset of move fast and break things (thanks Mark Zuckerberg), often times customer interviews and getting to know how users interact with your application fall behind. At SpotHero, we have recently graduated from the “startup” product style of push as many things through as possible to a more mature and calculated product lifecycle. Product vision, no longer determined by emotion, rather derived from sound metrics – is executed through the product roadmap, with clear and measurable goals in mind.

Determining what goes into your product roadmap to execute on this vision can be boiled down to two things: quantitative and qualitative research. From a planning perspective, quantitative research and feedback is pretty straight-forward – note: I didn’t say easy. Ensure all correct funnels and events are being tracked, analyze, and pull out key trends (to over-simplify).

The “art” of determining the product roadmap comes through qualitative research. Being able to pull the pain, motivations, problems and reasonings behind every user interaction in the application and finding tangible solutions to these problems is both critical and challenging.

Knowing minimal amounts of what was involved in customer interviews and gathering qualitative feedback, Chris Butler, my mentor and friend pointed me toward the Jobs-to-be-Done (JTBD) methodology. If you’re not familiar you can find it here: JTBD Interview Structure

Like Newton’s first law of motion – an object at rest will stay at rest – often the hardest part is finding where to start, and then actually starting. Personally, I have found it easiest to put together a quick project (product) plan that lays out clear goals with target dates, helping me reach towards a goal. The 20 day plan begins here:

Image result for plan

Day 1: Create User Segments

Creating users segments is the act of defining groups of customers that use your application, usually based on purchasing behaviors. After much deliberation, I eventually narrowed down my user segments from 6 to a more manageable 3. The process was simple – find the majority users and optimize for them. I found the other segments I created were around edge cases, which ultimately would be uncovered in talking to the primary users.

  1. Segment 1 – Users who have purchased monthly parking through SpotHero and still parked

  2. Segment 2 – Users who purchased monthly parking through SpotHero and cancelled

  3. Segment 3 – Considered purchasing, but didn’t

  4. Segment 4 – Users who started purchasing monthly through SpotHero and decided to stop

  5. Segment 5 – Users who are thinking of purchasing monthly parking, don’t know about SpotHero

  6. Segment 6 – People who buy enough daily parking to make the switch to monthly parking make sense

Day 2-3: Communication Plans for Segments

  1. Segment 1 – Pull list of users from database and offer customers $30 off future monthly purchase in order to have a 15-20 minute conversation with us.

  2. Segment 2 – Pull list of users from database and offer customers a $25 amazon gift card in exchange for a 15-20 minute conversation with us.

  3. Segment 3 – Using our analytics tool find users who dropped off in our sales funnel before purchasing, and reach out offering a $25 amazon gift card to have a 15-20 minute conversation with us.

Image result for budget

Day 4: Determining Budget

Of all the things, this one was the most unclear to me. I wasn’t sure how to get the conversation started, and when I did, it never really went anywhere. To resolve this, I did three things

  1. Pulled numbers on the impact of monthly parking for the company’s GMV

    1. This shows the value of reaching out to customers and justifies the cost for providing credit or some sort of gift card.

  2. Determine how many users I needed to talk to in order to reach qualitative significance

    1. 4-7 users per segment will get you all the information you need. Usually after 1-2 conversations, any glaring needs become apparent. Conversations 3-7 confirm and provide additional insights.

  3. Proposed number value of how much each outreach would cost

    1. Segment 1 – $30 in monthly credit

    2. Segment 2 – $25 Amazon gift card

    3. Recording Software – $10

    4. Total Budget – $395

Day 5-7: Scripts for Interviews

Simultaneously with budgeting, I started building the scripts for the customer interviews using the recommended JTBD framework. The general framework I followed was:

  1. Introductions – get to know the customer’s background

  2. Point-of-Purchase – bring them back to the moment they purchased

  3. Finding first thought – what made they want to make the purchase

  4. Building Considerations – what were all the options they explored to solve the problem

  5. Searching – what was their experience looking for monthly parking with us

  6. Booking – what was their experience like when booking

  7. Post-Purchase – what was their experience after purchasing parking with us

    1. Cancellation Recap (if applicable) – what caused them to cancel their reservation

  8. General Questions – allow them to give feedback and ask questions

Day 7-17: Getting People on the Phone

Getting people on the phone was easier than I thought – once there was an incentive. I had originally tried outreach to customers to get on the phone without an incentive, and did not get a single person to email back. Once I introduced and incentive, I was amazed by how many people want to talk for $30 off parking/$25 dollar Amazon gift card. Beyond the expected cancellations and rescheduling, I was able to get my goal of 5-7 users per segment.

Recording the Interviews

Image result for recordingFirst thing to lay out – record your interviews! I cannot iterate this enough. Not only can others in the organization listen to these interviews, but taking notes during the conversation takes away from the interview and makes the interview very choppy as you scramble to write down everything the customer says.

During the interview, I found it was good to stick to the script as overall architecture and gave good reference points to go back to, but the most useful product information came from the tangents or stories that occurred only through natural conversation. The script should act as a guide, not the thing you read to customers, get their response and move on. Don’t be afraid to go into rabbit holes or pry a little more. Know when you’ve gone too far, and reference back to your script to bring the conversation back.

Day 18-19: Reviewing Feedback and Building Roadmap

By the 2nd conversation you’ll notice hints of trends and by the 3rd or 4th conversation you will be able to confirm. Even if you product is “flawless” – which it isn’t – customers (or all to often, investors) will find issues with it. The key is to listen for their problems and not their solutions. Chris taught me a great prioritization technique through questions:

  1. How much time do users spend on this problem or trying to solve this problem?

  2. How frequent do users run into this problem?

  3. What’s the impact of this problem?

  4. Will this problem stop users from using your product?

  5. Would a solution for this problem drastically change consumer behavior?

Answering these questions helps you put an apples-to-apples comparison against all the feedback you get from customers. A good equation for determining priority (higher the number, the higher the priority):

# times occurs * seconds it takes customer to solve + 100 if deters user = significance

The output will give you a list of problems in priority. You still need to determine if these can be solved with or without product solutions.

Wrapping it up

As you’re looking at your product roadmap, it’s important to make sure those solutions being built to achieve this roadmap are being built for the users of your product. I DO NOT promote the product roadmap being a list of static features that solves the problems. Rather, the roadmap should be a nimble document that lists out the problems you plan to solve for customers in priority order.

Customer needs change, and what you think is the most important today, will not be the same importance 1 month out, certainly not 3 months out. Set expectations within your organization that the product culture and roadmap will be to solve the biggest problems currently facing your customers. I challenge you to go no further than 3 months out and to always be gathering customer feedback both quantitative and qualitative to make a product that best solves your customer’s current problems.

Image result for feedback

Afterward

With all the above being said – we don’t work in a vacuum. Things come up, priorities change, and ultimately leads to many reasons why it won’t get done or can’t get done in 20 days.

Here are some things that got in the way for me, and how I worked around it.

Focus

Depending on your product culture, you may have more than one product you are focusing on. In my case it shifted many times throughout the twenty day period – our internal admin tool, monthly focus on web, external admin tool for parking operators to bugs and general run-the-business type features.

Key is to keep laser focus. It’s ok to miss a couple days, but similar to working out; the more days you miss, the harder it is to return. Be transparent with others in your organization about what you are doing, and don’t be afraid to tell people no or not right now. Make sure you are clear on the why and benefits what you are doing brings to the company.

Priorities

This was probably the hardest part for me. One week I was focusing on one tool, the next another. Each of them shifting in priority based on our internal and external needs. Each had its weight of being top priority.

We’re product managers for a reason – we can decipher the important from the unimportant (and hopefully everything in between). Only one thing can be top priority. Make sure if something is bumping it off top priority, it truly is top priority. Working on one-off projects that come up – i.e. fires or must-have features – generally don’t lead to moving the needle. Ask yourself if you’re firefighting or product managing. Avoid the former when at all possible.

Resources

This is a fun one. You go out, do all your research, and you hit a wall because there aren’t enough design resources, engineering resources, data science resource, whatever resources… you get the point.

Don’t let this stop you, and should certainly not be an excuse. Do what you can to get it to the point where you could hand it off, and if it never makes it there – that means there were other priorities that took it’s place. If this is your top priority, make it the top priority of your teams to get it done.

Remember, as the product manager, you represent the customers needs in every decision you make. The best way to arm yourself with what the customers are currently facing is to get in front of them and have a conversation. This not only builds brand loyalty, but ensures that your product will be solving real problems. You have the power to get in front of them – if you don’t, someone else will.

About Jeffrey Owens
JeffOwensProduct artisan, aspiring Entrepreneur; adventure and travel connoisseur. Jeff Owens is on a quest. Reach out to learn more.

 

 

 

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy