It’s Not Ready Yet, but It’s Not What You Think: A Case for User Engagement before Market Engagement

One of the major hesitations from product stakeholders regarding end-user engagement, specifically user testing, is that they often don’t want anyone to see it till it’s “perfect” or “ready” or “MVP.” This is especially true of brand-new products or brand-new technologies. One thing we’re all on the same page about, though: It’s definitely not ready yet. But not because that bug still needs to be fixed or that color scheme should be tweaked. It’s because your target users haven’t weighed in.

Stakeholders frequently want to wait for a big reveal or a ta-da! moment—and that’s understandable, especially from a product owner perspective. For product owners, the product is their baby, or, if you will, their wedding. As a woman going the traditional route, you don’t go to your wedding half-dressed and with half of your hair and makeup done and ask the audience what they think before you finish; you wait for the big reveal. The difference here, though, is a major one: Your wedding is about you; your product is about your audience. If the audience doesn’t like your wedding dress, they might whisper about your choice, but in the end you just got married and you’re glowing and who cares what they think? If the audience doesn’t like your product...they’re not going to adopt it. And that’s a problem for all of us.

So what’s the solution? Identify user adoption risk early on by—yes!—talking to target users who can (who will) make or break adoption. They’re not going to judge you if your product isn’t “ready” yet; they’re going to tell you how to make it ready. They’re not going to care if the color scheme isn’t quite right; they’re going to tell you it’s ugly so you can change it.

Here are a few common scenarios that might resonate with you and your team:

Scenario 1. Featuritis

We’ve got a revolutionary product idea. It’s going to be awesome. It’s going to have all these never-before-seen features that will disrupt technology and software forever. Oh, and we should also add a few other features too so users feel like we are a one-stop shop. And some other ones so they think they are the smartest users in the world. Go! And hurry up because we’re launching any minute.

...Now we have a huge list of features and a timeline that’s a little hectic, but we’re still going to make our users so happy! Let’s start building features. The easiest ones first. No, wait--the hardest ones first? Let’s just give our developers the list of features and they can decide where to start.

...And now we have a slightly Frankenstein-esque product that we can’t launch because there is no cohesiveness, no logical workflow, and no user happiness. Some things don’t work because they need other things to make them work that haven’t been built yet...So let’s keep building the rest of our features until it looks like a product someone might use, I guess?

Our users are way better at prioritizing features than our dev team. We should have asked them to rank all the features in order of importance, and to let us know which features weren’t even useful at all. Would have been a more fluid process and we maybe would have met our deadline…

Scenario 2. Stakeholder Creep

Our product is finally getting off the ground! Out of our heads and board rooms, into a real, live, interactive thing!

The product owner works with the design team to make it great. The dev team starts building. Then project stakeholders start joining the weekly demos of the build. They start asking questions. They start poking holes in how Feature X works. They ask for a redesign. So the product owner works with the design team and the dev team to refactor. Then more stakeholders, who have more say and less time, start joining the weekly demos. They start asking different questions. They start poking different holes in that same Feature X. They ask for yet another redesign. Back to the drawing board for the product owner and design team, and a scramble for the dev team to try to salvage some—any—of the code they’ve already spent so much time on.

Ultimately, we’ve gone through 4-5-6 sprints building and then rebuilding Feature X, when it should have taken 1.5 sprints total according to the initial estimates. At $50,000 per sprint, we’re working way overbudget.

It would have been easier—more cost-effective, less time-consuming—to just ask users before we even started building. They know better than the ever-expanding round table of stakeholders how Feature X would be most useful—and they’re the ones who are going to decide whether to buy it. Plus, it’s much simpler to convince stakeholders of a bad idea with real data to back it up.

Scenario 3. The MVP Launch

We’re finally ready to go to market with our MVP! It’s so exciting! We’ve been designing and building and rebuilding for months, and now it’s finally there. We’ll do one quick round of user testing just to identify any gaping holes but there probably won’t be any.

User testing with a sample of our major target audiences is not as successful as we’d hoped. Turns out only 2 of the 3 target user types actually finds any value in our product. And only 1 of those 2 would buy a subscription to the product as-is. That’ll account for less than 1/3 of our expected revenue.

Does this finding represent our real target end-users or did we end up with a random sample of edge cases? Is it worth risking it and going to market without digging deeper? Will our investors pull out if the prospective user base is cut in half?

If we’d gotten user engagement beginning with a proof of concept and going all the way through to maybe some interactive designs or a rapid prototype, we’d have a much better idea of what our users want and how we can delight them. We’d also have a clearer definition of who our users are—and aren’t.

Bottom line: In the end, everyone’s goal is the same: Build a great product, get market leverage, and make our users happy. For a successful market engagement, you need to start with user engagement, and keep going with it. It’s never too early—or too often—to engage your end-users for help getting the product right. Product discovery, design and realization are, at least in an agile world, iterative processes, and you should be getting feedback “early and often.” They’ll help you prioritize features, build a product roadmap, identify gaps, and ultimately evangelize your product.