You've just finished an interview. It was amazing, you gathered a lot of interesting information and you're excited to share it with your colleagues. But what is the best way to share it? This article outlines the process that we use to create the interview snapshot that will help us remember the core details of the interview as well as be a quick and easy way to share the information with our team.
The interview snapshot
At ZeroBlockers, we have taken the interview snapshot template promoted by Teresa Torres in her book Continuous Discovery Habits, and we have modified it a little to align it closer with the model that we are working within.
There are six key sections for an interview snapshot:
- The context: Who is the person being interviewed and what is their background?
- The motivating forces: What is the problem that the interviewee is facing? And what are the impacts of the problem? How much better will life be when they adopt the new solution?
- The hindering forces: The status quo can be very hard to overturn. That is why it is good to be conscious of the obstacles that are preventing the interviewee from solving the problem.
- Tradeoffs: Every product decision comes down to tradeoffs because there is no perfect solution. What we need to uncover is how our market thinks about the tradeoffs and which elements are a higher priority for them.
- Opportunities: Opportunities are pain points or unmet needs that the interviewee expresses during the interview. The important thing here is to list them as quotes because when you rewrite them into your own words you can often unintentionally introduce bias. Keeping it as a quote also lets people search in the video to get the full context if they would like.
- Process Flow: What is the process that the interviewee is using to solve the problem? This can help to identify the trigger moments that move someone through a buying journey.
The source material
For this article, we will be creating our snapshot based on our interview with Richard Rodger about the challenges of product development within the developer relations space. You can watch the full interview here:
The first thing we need to do is transcribe the interview because it is a lot easier to review the written notes than to have to search through a video to replay interesting parts. We use a tool called Descript to transcribe as well as edit our interviews but there are many AI models that are very accurate in transcribing audio these days.
Filling in the template
The context
Richard Rodger is the CEO of Voxgig, a developer relations consultancy. He previously co-founded NearForm, the world’s leading NodeJS consultancy and was also the CTO of FeedHenry. We need to capture this detail so we can understand the context of the interview.
The motivating forces
We need to separate the motivating forces into two different categories: push forces and pull forces. Push forces are the things that the interviewee doesn't like about the current state. Pull forces are the things that they believe will be better in the future state.
Richard shared three big impacts caused by the lack of buy-in for developer relations collateral and quality, specifically in developer-enabled companies.
- Slows down implementation: The lack of quality documentation, code examples and tutorials slows down the implementation of the product because the developers have to figure out how to use the API on their own.
- Increases support costs: The lack of quality documentation and tutorials leads to increased demand for support which reduces the unit economics of your deals.
- Slows down development team: The increase in support demands removes developers from building new features and products as they are supporting existing customers.
The pull forces are the companies that are doing developer relations well. Companies like Stripe and EverVault have great developer relations collateral and the business outcomes they achieve are a testament to the value of developer relations. In addition, Richard has a wealth of experience so he has seen how better working approaches can lead to better outcomes.
The hindering forces
Again we can split hinderances into two categories: habit forces and anxiety forces. Habit forces are the muscle memory that people have built up over time to solve a problem. Anxiety forces are the fears that people have about the future state.
Richard shared that a lot of the developer-enabled companies are used to having a business <-> IT divide, where the business are used to telling IT what to build. When building products though, you can't know what customers want up front and you need to do the necessary discovery and iteration to get a high-quality product. This is obvious to Richard and many in IT but it is a hard habit to break for many business people.
Tradeoffs
We didn't explicitly talk about the tradeoffs that Richard makes in terms of his approach to solving the problem. However, we can infer that he is making tradeoffs because, in an ideal world, there would be agreement up front on the value of developer relations and the quality of the collateral. But the fact that this is not happening suggests that tradeoffs are being made. The biggest one is that Richard needs to run a business so he needs to meet his customers where they are at instead of where he would like them to be.
Opportunities
There were many different quotes that we could pull out from the interview but here are a few that we found particularly interesting:
"You need a strong forcing function for change. Where's the forcing function for companies that are making money but leadership are not bought in"
ZeroBlockers is trying to solve the exact same problem that Richard is facing. We need to get high-level buy-in for the value of continuous discovery to build products that customers really want. This is not a solution but it is a great articulation of a problem that we, as a team, will need to solve in order for our product to be successful.
"Unless there is high-level buy-in and at the highest levels - founder / CEO, it ends up being a drag on the company that isn't organisationally understood"
Again, this is a great articulation of the problem that Richard is facing. The problem is that the symptoms are shared across multiple different teams and that each team will try, in vain, to fix the problem when the real solution is to change the way the company operates. And this can only be done with high-level buy-in.
"You want to avoid a feature fight: a big spreadsheet and there's supposed to be tick marks against each feature. And everybody's arguing about is it done, is it not done?"
Feature fights are a great example of the symptoms of the problem that Richard is facing. The problem is that the company is not aligned on what the customer needs and so they are arguing about what features to build. From our perspective, we need to validate if this is terminology that everyone uses and if so, it could be a good term to anchor against.
Process Flow
Finally, we can draw up a high-level flow for how Richard addresses the problem. He really tackles it in four ways:
- Brand: Richard invests a lot in building the profile of his brands, both Voxgig and previously NearForm, because he understands that this is the starting point for building trust.
- Demonstrate competence: Richard uses the concept of a trust battery. When you start an engagement you need to be strong on what you can deliver and by when. Which means saying no to things. But also ensuring that you do deliver what you say you will.
- Work collaboratively with clients: The goal is to build the trust that you can push back against the spreadsheet of features and instead focus on the customer's needs. This is risky for the client but it is the only way to build a product that customers really want. That is why the first two steps of building trust are so important.
- Iterate: Build and iterate the product until you have something that customers really want.
Conclusion
We gathered a lot of really great insights from this interview with Richard. The most important thing from our perspective is that we have validated that Richard is not actually a customer for ZeroBlockers. We are trying to solve the same problem that Richard is facing so his customers would also be customers of ours.
Given that we are solving a problem that impacts Richard he could potentially be a champion for us. We need to validate this by talking to more people in the developer relations space.
Your thoughts
What do you think of this analysis? What would you have done differently? I'd love to hear from you as this is an art more than a science and there are always ways to improve.
And if you found this interesting you might also like our Interview Analysis series where we break down the questions that we asked in our interview with Richard to explain why we were asking certain questions, how we tried to direct the interview, the mistakes we made and the things we could have done. Check it out here: