MVP Series 1: I’m (possibly) launching a new product – want to follow along?
I no longer fall in love with my own ideas. I treat them like an unloyal friend that will just as easily tease me into a long road of misery as they might be a partner in a great adventure!
The reason is that your ideas will lie to you – well, technically they allow you to believe what you want to believe. They are the ultimate form of Confirmation Bias – one of nine bias types. Confirmation bias is when you give weight to a response and dismiss evidence that is contrary to your hypothesis. If you only have one idea – you are seriously going to dismiss that evidence.
It’s hard to hear that your idea is bad – it’s like hearing your baby is ugly. Founders tend to wave off this feedback as people didn’t get it or they were dumb to not understand the idea. This externalizing of the problem is very bad for the customer development process. Thus confirming what you want to hear.
With that as context for the post: I’m working on a new Minimum Viable Product (MVP) to test and see if there is a problem/need/opportunity in this specific market. I’ve realized that I have a bunch of steps in my head that I haven’t written down. I’m using this as an opportunity to blog about the process as well as including the information in a book I’m preparing called Startup Evidence (more on that later).
Do you want to follow along in the process?
I knew I would lose some of them… For those that stayed, let me tell you more about the product.
Startup Hypothesis
The MVP idea came from my legal friend and partner. The mobile app that automates the Engagement Letter process for the demo and value proposition. The hypothesis was that Attorneys would like to use their mobile phone to take notes on new clients and then automate the process of the engagement letter. As a client, I know I’ve received these letters in the past as an email attachment. Then I had to find a printer and scanner to return the executed copy of the agreement.
We did some initial customer interviews and built out the wireframes for the iOS version of the product. We had it built by one of my former students from Code Fellows who built an iOS version of what I would call “slideware” – it worked on the phone but didn’t plug into anything in the backend or really capture any data to store.
Step 1: Wireframing Process
Wireframing is a simple process of outlining the function of the App or Website before you build anything. It’s a slideware/powerpoint version of what you’re trying to demo.
I use a tool called WireFrameApp.io. There are a lot of tools out there, and by the time you read this, I may be on to another tool of choice (list of tools including Balsamiq). But what I like about the app is the ease of use via browser, the ability to collaborate (invite others), and that it’s touch friendly. So you can actually demo functionality without writing Swift or Android.
Process flows. Start with the process flows of the app or website. You’ll be able to move them around later. Stay big picture and crank out the basics of the pages. You can make a copy of any of the pages to add features later.
Export this wireframe to a PDF or PNG and load it on your phone or tablet to give the demo. Again, you can do this without writing code.
Wireframes don’t look great. But they communicate the idea. Design is important – however, at this point, design follows function. Start with a site or an app that you like – or a competitive site. More on Design – go here.
My goal while the mobile version was being built was to interview 25 attorneys and legal firm staff in the last two weeks. I was able to get about 20 interviews done in person/skype and phone – a few more filled out the survey online. We shipped the first version about halfway through the interviews. Keep in mind, this was a before work/after work process of interviews.
The method was in descending order to do customer development:
- In person – across the table and watch how people react to the demo
- On Skype/Hangout – where you can see their face
- By phone – where you can’t see body language
- Least valuable – a survey
You want to be able to dig into how people react – or don’t react – to your hypothesis and ask the why questions that need to follow.
Step 2: Problem first – then features – then an App
Let me note here that many people approach this as an App with Features that maps back to (hopefully) find a problem. The better approach is to start with having an acute focus the Problem, not the solution. Then with the feedback, you can define the features and finally answer the question of what the final use case will be, for example, a mobile or web app.
Why is this important? As you talk to potential customers you’re going to dig into what problems you’re really solving (setting aside gaming and entertainment for now). And is it really a problem – which will translate into: is it a big enough problem to warrant their time and, ultimately, are they willing to pay for said solution? Which means the first version you ship isn’t likely to be the version they will pay for… So, the problem first, please!
How did it go?
OK, given the setup, let me walk you through what we learned – roughly in the order of discovery vs importance. Some of the discoveries were major, some minor, and some pointed to a sales process that we had yet to discover.
- The size of law firm mattered – the large firms have complex client intake processes that aren’t generally automated, though they are documented with a Standard Operating Procedure (SOP)
- Complexity was viewed as a non-starter for a simple App to address
- Type of attorney mattered – attorneys who had maybe a dozen clients in any given year didn’t find any value in the demo. They viewed it as transactional where they were relational
- We found some fields lacking in the demo – we had designed for corporate law and excluded the Open Text Box for opposing parties – who you’re litigating against
- Even with good wireframes, we found things we missed. Wireframing is cheap vs building product
- We also found that a pick-list was a good way to select from multiple templates for larger firms
- Pricing was a question – both “how much does this cost” when we waited until later in the conversation. We also would ask “how much would you pay” if it didn’t come up earlier in the conversation.
- The goal was to land somewhere in the competitive range
- We also learned that if we were able to take online payments for a deposit or retainer that price became a secondary issue
- It seems law firms don’t have a good way to take deposits or retainer via only payment systems – hmmm, maybe an interesting idea for later
- This would require a payment gateway at the backend of the process vs. a Square or Swipe type payment at the lawyer use case
- One mistake we made was thinking about our personal use case as the actual users – the Lawyer and the Client. We found that the staff person was ultimately more influential as the user than we anticipated
- Staff influencing product adoption – they are the “Influencer” buyer
- Ultimately, the profile of the attorneys whom I interviewed was not the profile of the user who we think will ultimately buy the product – see more below
Why is it always conflicting or inconclusive?
The more customer interviews you do the more data you’re going to gather. Don’t anticipate an “AHAH!” moment or epiphany. Though that would be amazing, it usually looks more like a “That’s interesting” moment and is a head scratcher.
For example, I heard a number of times, “I see how people would use that, but not me/us/our firm.”
Here’s where bias is particularly tricky… they’ve confirmed your hypothesis! Yeah… but wait, they are saying it would work for someone else, not them. Huh?!? So they liked the product, but not for them.
Human nature at this point kicks in. I don’t want to have wasted my time doing these interviews. The suspects have confirmed my hypothesis, but they confirmed it for a third person. What do you do then?
You go and do more interviews. Off to go interview some transactional (volume) lawyers – those who do more project based or fixed priced projects. For example, real estate, trademark, personal injury.
Keep in mind, the next decision is to spend a significant amount of cash on building the actual product. It’s a big decision.