Beta, MVP, Pilot—whatever you call it—this is the most crucial part of product development. And it IS the penultimate part of the product development process—not purely a marketing exercise to shore up a tag line and build out testimonials. Your MVP period is the time when product, marketing, and sales need to see your product in action and collaborate on your full go-to-market approach.
However, the reality is that very few companies (and I mean very, very few) are equipped or patient enough to use the beta period as a true test of the product AND the customer experience. The good news is that with some planning, communication, and a bit of an adventurer’s attitude, your beta period can deliver an authentic picture of how your product performs “in the wild” AND develop your pilot participants as first adopters. As we enter the all-important pilot/beta/class test season, this is the time to understand both the product and the customer experience so you can go-to-market fully prepared.
1) Bring your customer in earlier. You probably already knew I would say that. Not a whole bunch of them at first but a few chosen folks with whom you have had conversations, observed, and who you trust to help you. And here is a clue. If you—as a product person, a marketing person, or a sales person--do not know a single REAL customer who would LOVE this new product if it does what it promises to do, you don’t have a product. (If you build it, they will not come). I love crafting customer journeys and believe that they are extremely helpful in guiding development. But so many of these that I have seen are intricate works of fiction--profiles of customers companies imagine, not those they often serve. And, it goes without saying, if you fear exposing your in-development product to a real customer, you are in trouble.
2) Stop the surveys. Pick up the phone. Oh, the surveys I have seen. Let’s survey the faculty member! Let’s survey their students! Let’s do it weekly! Surveys are useful and at specific times for specific reasons they should be deployed—pre and post implementation surveys provide good data around change. But the information is flat and limited. Instead think about the cycle of your product and plan to check in during crucial times like onboarding, after the first assignment, after the first assessment. There doesn’t have to be a litany of survey questions approved by a cast of thousands, just a simple script: “Professor Craig, I just wanted to check in and see how the onboarding was going. What has your experience been so far?” See? Much better than asking them to fill in their name, school, course schedule, position…..you get the drift AND the information you need.
3) Separate your content SMEs from your workflow SMEs. When I was first starting out as an editor, so much of what we reviewed was the quality of the content. After all, it was a book. Easy to understand the customer workflow. With today’s technology projects, I find it is better to separate out the content reviewing and workflow reviewing. With the first, you are checking on quality and coverage. With the second, you are checking on usefulness and usage. A Subject Matter Expert is good for reviewing the first; a teacher fluent with all of the challenges of today’s classroom is necessary for testing the second.
4) Be specific about what you are testing. Don’t make them guess at what you are trying to do, tell them. ‘Please comment on the assignment feature’ is unlikely to provide actionable information. Instead, be more pointed. “This feature was designed specifically to make it easier to assign extra practice to students who are struggling. Does this do what it promises? How would you envision using this? How often do you envision using this? Does this streamline the process for you? Why or why not? How could this process be improved for you?” The greater the specificity, the more actionable information is revealed.
5) Be ready, willing, and able to see failure. If everything is working great in your beta, your customers aren’t using your product. At least not in the way you intended. It doesn’t mean that all customers have to use all of the features, but if your value proposition is around “smart practice that gives instructors data to better guide instruction” but you are not seeing sustained usage of the smart practice feature in your beta, well, you might want to change your value proposition. And keep in mind that sexy, while giving reps something to talk about, is hard to pin to improved, measurable outcomes.
The truth is the most product teams are excited to “beta” their products but once the beta site is secured, the rest is relegated to templates, process, and assistants to manage. Unless your product is a spreadsheet, templates and process will never deliver the kind of learning and the kind of long-term customers that a human-focused pilot can deliver. At EyeLevel, we always put the customer at the center of the experience. And that will provide all of the learning you will need to Go-To-Market confident that the market will respond as planned.