Business Model Validation
In part 1 I wrote about how we’d fallen into the optimisation trap after a pivot in the business model. We still had experiments, and we’re attempting to validate our remaining hypothesis, but our means to doing so weren’t bold enough nor structured appropriately to achieve their aim meaningfully. What brought about this pivot was an analysis of the marketplace and qualitative feedback from our rapidly expanding transporter network, the challenge inherent in a two-sided business model was balancing the needs of both.
In any event it meant we had a working version of the business model (a Minium Viable Product), with some new features and changes made, that we could use to re-validate the problem-solution fit and confirm/test the problem-market fit. I write re-validate because our original business model had now changed and we now needed to retrospectively complete business model validation.
On a more positive note we had an established customer base that we could leverage and they in turn could point us towards others who hadn’t yet, but might, use the service in the future. It was important at this point to get feedback from as broad a selection from our target market, and some potential but un-tested markets, simultaneously which were:
- Customer who’ve used our courier network before
- Customers who attempted to use our courier network but didn’t
- Online shoppers who’ve never used Scurri
That’s not to say there other customer segments to test but our more immediate term was on the online shopping consumer base. In addition to validating the problem/solution fit we could work with this segment to start building and testing our selling process as soon as possible (Ash Maurya writes about this in his blog). In our instance we would:
- Instead of verbalizing the unique value proposition, we would show them the landing page (and later revised mock ups) and test its positioning
- Review how the use the service and note where they’re getting stuck, frustrated or confused.
In applying customer validation we used elements of both the Problem/Solution fit and the Problem/Market fit, as outlined Eric Ries’ book The Lean Startup, to validate our business model. By having the MVP working we could also elaborate on some features, or lack thereof, and validate our assumptions of the same.
One pitfall we fell into rather early was that invariably, without proper structure, we’d talk about actual features and our conversation would steer to what the customer wants as opposed to what the needs of the customer (which isn’t necessarily an actual feature). We had to stop validating the product! I found that by not showing the product until very late in the process we could be more constructive by focusing on validating the problem.
In some instances it seemed to be more beneficial to use just the mock-ups as some people were more inclined to critique the design of a live page (which is valid to a point but should happen later in the conversation).
What did this mean? By the end of the customer insight, which incidentally took about a week and a half, we had plenty of feedback from different channels and some very clear trends had emerged. This fed into the redesign to increase conversion rates, helped prioritise features and more importantly, took us out of the optimisation trap and focused on the more important things.
And that’s not to say the learning circle stops. We now have a Kanban board to prioritise our features where everything is validated qualitatively before we build it. Our new designs are wireframes which we use to go back to some of the customers, and to new ones too, to validate we’ve got that right. All of this means we should have a service that works perfectly for the needs of the market we’re attempting to address. Watch this space on what that all looks like!