Now the product has a backbone there needs to be a consideration for the business processes! Start to look at automating the onboarding, but with a focus on the experience these new customers have. (It’s worthwhile looking at page 13 of AJK’s roadmap http://getting2alpha.com/downloads/Getting2Alpha_Breakthrough_3-Game-Thinking-Blueprint.pdf - we are between stages 2 and 3). Your aim is to remove the barriers to USING product. Your about to start getting leads and the last thing you need is a leaky bucket once you’ve got them through the funnel.
One of the common areas that can be an obstacle is data import. If your product needs a backlog of data to be present before the user can start to gain a benefit you have a BIG on boarding problem. Find out how you can reduce this need. Look for alternative user journeys to ease the pain during the initial data loading phase. Can you scrape other sources to help prefill/default lengthy data fields? You want to try almost anything to avoid a traditional data import – invariably the source data will be inconsistent and this will lead to crap data in your pristine new system which will only look bad on you! Remember - Rubbish In, Rubbish Out and you’re spending a load of marketing money telling them their old system is rubbish!
This is where the practicalities of being a new user becomes key. You are starting to think about expanding the user base and the problems that this causes. I rarely find people properly define the requirements for this stage of the business and fall foul because of it. The first few users should become your evangelists, but if they have had an awful time getting started it isn’t going to happen. Using the phrase “it is a beta” only excuses so much and rarely the important first moments of the “on boarding” experience.
As a guide, it should appear to the customer that they fill-in an online form, an account is created and they can use the system. How will the new user get started? Should there be basic help available? How do they contact you for hand holding? Now step back and try to impartially answer: How well does the new user get to grips with the functionality?
Aim: To test product feature set and intuitiveness of product. If they can’t get started then it will be difficult to get the answer!
This is the logical step after you’ve gained the commitment (and the enthusiasm) from your superfan to use your product. Focus on what needs to be added so that more than one user from the company can perform the task. It’s likely to be login (and the associated authentication, authorisation issues), filtering data by user, basically multi-user functionality. There is still very unlikely to be the “need” for reporting and advanced dashboards. You can create the users manually in the database if needs be…no need to worry about “admin” or “settings” pages yet!
This definition is the minimum that I default to when someone says “MVP” without any further clarification. It has a real focus on the bare bones of what is needed to solve the customer’s pain point.
From this point on, the driver for expanding the functionality should be taking feedback from the users as a primary influence. You still need to stick to the vision of the product, but the minor alterations in direction are best influenced by those people that actually perform the job. It is at this point that the Product Manager / Owner role becomes so key… but that’s for another post!
This is probably the most important Minimum to define and build. It allows you to answer “Do any unforeseen practicalities affect your value proposition?”
What is truly needed for a single individual to road-test your brilliant solution to their problem? Be ruthless, focus on the core loop. Why build Dashboards when you haven’t even worked out how the core functionality works?!?! This is the hardest “minimum” to build, but could very well be the crux of getting your product to launch! The key point of this “minimum” is that an end user can perform the real world activity for themselves.
It can be quite contentious as whether something is needed or not… keep focus on the key user of the system - the persona who gets the work done. You might need some reports, bells and whistles and USPs to push someone to buy your product, but if doesn’t actually do the core job well you might as well forget it for this target.
A useful example is to look at an existing product and retrospectively see if you can see what would have been needed to create this “minimum”. Take “twitter”: no need for notifications, no need for DM, no need for embedding images or tinyURLs. In fact, a true minimum would have worked with an imaginary list of “follows”. All you would need is the ability to enter some text and “tweet” it, and then the ability to see a list of the other “virtual” user’s tweets.
Think of this minimum as a sales pitch to your super-fan. What needs to be demonstrated so that they want to use it now. The detail of this minimum depends on the nature of your relationship with the super fan. At one extreme this could be done using the same artefacts as the UX prototype, at the other, they may expect to be using it the next day (see minimum 7)!
You are really after feedback that confirms you are on the right tracks for a viable business. The earlier UX test tends focus on the practicalities of using the software, but you also need to find out whether a business will find it useful. You want to leave this demo with a commitment from the super fan to use a working version of this demo. I have several personal examples where the commitment never materialised. “If it just did this one extra thing” is an easy way for someone to postpone telling you the truth that in fact they don’t want to use your product, which in its own way is hiding the real statement of “I don’t value your solution”.
