You’ve no doubt come across the quote, “If you build it, they will come.” The reality is, however, that when developing any new product, the building part comes after a lot of other important stuff – like identifying your customers’ needs and your value proposition.
This is part 2 in our 3-part series on how we built Robot Ninja, our automated checkout testing product for WooCommerce stores.
We’re not delving into the technical aspects of how we actually built Robot Ninja here. Rather, exploring the process and methodology behind how we came up with and launched a new product.
In part 1, I outlined the process behind how we came up with Robot Ninja and explored some of the tools and techniques we used to determine our goals and target customer, and conduct market analysis and research.
In this post, I’ll build on steps 1-3 covered in part 1 and further explore how we:
- Identified underserved customer needs. How we leveraged our hypothetical target customer and researched data to conduct customer discovery interviews.
- Defined our value proposition. How we used the knowledge and research we gained in previous steps to decide which needs and benefits the product we wanted to create would address.
Step 4: Identifying Underserved Customers Needs
Building on what we’d learned so far, the goal for us during this stage of the process was to build and validate our knowledge of the problem spaces we had identified in previous steps and validate our hypothetical assumptions around them, i.e. target customers and their needs.
Customer Discovery Interviews
The bulk of our time was spent conducting customer interviews with people who fit the hypothetical personas we created back in Step 2 when we were defining our target customer. As we talked to more and more people we were able to further refine these personas until we had gained a solid understanding of who our target customers really were.
Finding people to interview was tricky. To help present why we wanted to interview people and attract the right individuals we set up a research site with a couple of different calls to action for different demographics based on our personas. We also offered an Amazon voucher as thanks for their time.
Next, we put out a call on social media and invested in some cost per click advertising through Facebook to direct people to our research landing pages.
Individuals were asked to complete a form answering some basic information about themselves to register their interest. This step was purely to help us weed out those who simply wanted the voucher.
We then contacted individuals who actually matched the demographics we were interested in and asked them to select a time in our Calendly calendar that worked for them. As both Matt (the other developer on this project) and I are based in Australia, this meant a lot of late nights and early mornings attempting to catch individuals in European and American time zones.
For a couple of introverts like us, the process of talking to people was very challenging, but after some practice it turned out to be quite rewarding (with the exception of the times that a call would be scheduled for very late at night or very early in the morning and the individuals would not show or answer…).
In terms of how we conducted the interviews themselves, we came up with a comprehensive questionnaire, which you can check out here.
We found the most important things to remember when conducting customer interviews were:
1. Do not talk about the idea/solution
The interviews were about the customers and their problems – do your best to keep the conversation focused there.
2. Do not ask about the future
No hypotheticals, no projections, no guesses. Never ask a question with the word “would,” like:
- “If we built a product that solved X problem, would you use it?”
- “How much would you pay for something that did X?”
- “Would you like your existing solution better if it did X?”
When you use the word “would,” you’re making a thinly veiled attempt to validate your product, not their problem. Don’t do that.
3. Empathize
This helps build rapport with the customer and leads to better and easier communication. Statements that demonstrate empathy include:
- “I’ve experienced exactly the same problems myself.”
- “You’re not alone there. I’ve talked to several other people who have said the same thing.”
- “That makes sense.”
- “I can see why that’d be hard.”
We developed the script based on concepts from a few different sources. The most useful resource was Customer Development Labs. It provides some great articles and tips on how to conduct interviews, and more broadly around the topic of lean startups.
I should also note that we used the script as a guideline or prompter – we didn’t simply run through the questions as quick as possible. Sometimes the conversations went way off course as we followed a tangent or explored a relevant line of discussion. Other times, seeking answers from people was like drawing blood from a stone and the script provided was a useful checklist for simply running through the questions. As long as you touch on the important points and be a good listener (or record the interviews – see below) you’ll get some great information.
We mostly used Skype to conduct the interviews because it gave us the flexibility to call real phones as well as do Skype calls in either video or voice (we gave people the option). Depending on the individual, we also recorded the calls primarily so we could play them back and take notes later. This allowed us to focus on building rapport with the individual without the distraction of taking notes. For many people like myself, the constant noise of tapping away at a keyboard can be very off-putting.
In total, we ended up interviewing several dozen individuals. From these interviews we were able to:
- Iterate on our personas and refine our demographic data.
- Build relationships with people who could later help us test product ideas in the future.
- Identify a number of broad themes and get a rough feeling for those that were more common pain points.
The following image outlines a sample of some of the common themes, pain points and problems that were identified during our interviews.
As you can see, updates and testing were the most frequently mentioned and discussed pain point in our interviewees.
Step 5: Defining Value Proposition
A value proposition is, essentially, a positioning statement that explains what benefit you provide for who and how you do it uniquely well.
For us, the difficult thing about defining our value proposition was having to say “no” to some things. After all, we couldn’t solve every problem identified during our interviews.
To help with the decision-making process, we used a combination of techniques from the Lean Product Playbook and Blue Ocean Strategy to help us work out what to address.
This was also the point in the process when we decided which problem spaces and customer needs we needed to focus on over others.
Importance vs Satisfaction Framework
The Importance vs Satisfaction Framework is a tool from the LPP that we used to help evaluate and prioritize needs and is based on customer value (as a function of importance and satisfaction):
- Importance is a measure of how important a particular customer need is to the customer.
- Satisfaction is a measure of how satisfied the customer is with a particular (typically the existing) solution that provides a certain customer benefit.
Mapping the needs based on their perceived importance and satisfaction then helps to identify if:
- There is an opportunity,
- The space is already too competitive, or
- It is not worth going after.
Here’s an example: Something that is arguably very important to a store manager is having a working checkout. If your checkout isn’t working, you don’t get any sales. Simple. But there are lots of issues that can arise as a result of not having a working checkout, such as:
- Negative customer satisfaction
- Increased customer support/service
- Loss of reputation
- Wasted time and resources from manually testing the checkout is working or trying to diagnose/solve/fix a checkout
- Anxiety and worry that your checkout isn’t working
Determining the importance of user need can be fairly easy once you have a feel for (and can empathize) with your target customers and their pain points or problems.
However, determining satisfaction with current solutions is a little harder to do. For us, we were able to get a feel for this during the market research and analysis and interview steps of the process, simply by asking interviewees questions like:
- When was the last time you tried to solve that problem?
- How did you go about finding a solution?
- What isn’t ideal about current solutions?
You can see why the customer interview process is so important – it really helps you make more informed decisions.
Strategy Canvas
During this step, we also developed a Strategy Canvas (from BOS) for our problem space that plotted potential competitors against a range of competition factors. This forced us to look at potential competitors within the space and identify what would need to focus on to set us apart/differentiate from their offerings to ensure our value proposition was unique.
Focusing on the E2E testing space, we looked at factors such as:
- Cost effectiveness – Comparison of cost, including the people power cost e.g. in the case of manual testing, a person would need to run the test and that costs money.
- Ease of setup – Comparison of how easy it was to start testing.
- Easy to maintain – Comparison of how easy it was to maintain, taking into consideration things like whether the option required a store manager to update tests when a new version of WooCommerce is released.
- WooCommerce focused – Comparison of whether the option was focussed on / deals with WooCommerce-specific issues.
- Workflow integration – Comparison of how well the option integrated with CI/workflow systems.
- Integrations – Comparison of how well the option integrated with other popular systems, such as Slack for notifications.
- Flexibility and Customizability – Comparison of how well the option handled custom tests/situations/sites.
Here’s an example of one of the strategy canvases we put together:
Four Actions Framework
Using the Four Actions Framework (also from the BOS), we then eliminated, reduced, raised, or created different competition factors from our strategy canvas to help us get an idea of what we needed focus on to leverage gaps in existing solutions. Specifically:
- Eliminate – Which factors/features/functionality in the market/industry that existing competitors compete against could we eliminate and essentially not focus on?
- Reduce – Which factors should we reduce our focus on in order to capitalize on others?
- Raise – Which factors should we raise or increase our focus on and provide a better product than that of our competitors?
- Create – What new factors could be introduced that no other competitors offer?
This process of identifying and filling the gaps in the market is where the concept of Blue Oceans and uncontested market space comes into play. What you want to end up with is your own strategy canvas, similar to the following, which you can use to help guide your decision-making process (including deciding what features to implement):
When developing your own product, you’ll obviously want to revisit and review the canvas as your market and industry evolves and you get more information and feedback from customers.
Wrapping Up
That concludes part 2 in our series about how we built Robot Ninja.
To recap, up to this point we’ve:
- Defined goals for the project to help guide our decision making,
- Identified some problem spaces and hypothetical customer personas to validate and iterate on as we investigated the problem spaces,
- Actually conducted research into our problem spaces using hypothetical personas we’d come up with as a starting point,
- Interviewed people matching our personas within the problem spaces and validated how well they matched, iterating on them as needed and interviewing more people; and
- Decided on what needs and problems we would actually try to solve based on all our research and information gathered so far.
In part 3 of this series, we’ll move on from the conceptual stuff and explore our solution, including the features we wanted to build and how we created a prototype of Robot Ninja.