Be in the market before you go-to-market

As I like to tell my 15 year old, in the immortal words of Genesis, “you’ve got to get in to get out.”  While he usually sighs and rolls his eyes (he is a teen), he knows that means that he has to do something, experience something FIRST before he can decide whether he likes it or not.  You can’t just say “I don’t like non-fiction books” if you haven’t read a non-fiction book.

The same is true of your product—it’s got to get into your market and to your customer—before anyone (other than you and your revenue projections) can decide whether or not they like it.  No sales presentation is going to elicit “wow! I am going to change the way I teach/take a different approach/change my lecture notes to use your product” if they haven’t ever experienced it.  Beta, MVP, Pilot—whatever you call it—this is the most crucial part of product development.  And it IS a part of product development—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 go-to-market approach. 

However, the reality is that with revenue pressures being what they are, new product launches/major updates are often “moved up” to fill 4th quarter shortfalls, and true opportunities for market development, product development, and testing the product/customer relationship get pushed aside.  Then, instead of collaborating on the best go-to-market strategy, product teams fix errors, marketing teams smooth over bruised instructors, and sales reps hope like hell this hasn’t destroyed customer loyalty.  And your product, while benefiting from corrected errors, does not improve. Turns out your MVP is really a fully-baked product (with fewer bugs).  What is worse is that the beta/MVP product is often brought to market and sold at a reduced “beta” price which covers everyone when errors start occurring.  It is very easy to identify which products and which companies give lip service to building an MVP and then throw it into the market without this testing period.  Perhaps it shows up as an “easy to navigate platform” that is NOT easy to navigate or “intuitive tools for more efficient study and practice” that are not intuitive so they don’t improve study time or “integrates fully into your LMS” as long as there are IT teams to figure that out. 

So, if customers need to experience your product before you go-to-market but the realities of revenue pressure in a shifting market will more likely force a change to your schedule, what can you do?  How can you get in to get out?

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)      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.

3)      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.

4)      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 increase retention” 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. 

And in the end, that is what your product needs to deliver.

If you are going to build the plane while you fly it, count on EyeLevel to be your unflappable crew.