I'm not going to user test...

...my product needs to be in market NOW

Posted by Jim Morris on October 12th, 2015

Delivering software on time can be a FALSE milestone...unless of course, you produce the right software the first time without having tested it with users....hah!

Instead of "Speed to Market", focus on "Speed to Product/Market Fit."

Maybe you’ll conduct user tests AFTER the software is delivered. Can you really wait for 2 to 6 months of development to get your idea into the hands of users for the FIRST time? You might be spending up to $20,000 per week for outsourced, in-country engineers to build your website or app. You could be wasting 50% or more of that money in throw-away software.

Here’s how to convince your boss, the CEO and/or the company that user testing actually saves time and energy.

Iterate with cheaper clickable prototypes, not valuable engineering time

By sending untested ideas to your developers, you’re just DELAYING the inevitable changes you’ll have to make to your website or app. In addition, you're spending more money (in terms of employee time) than is needed.

Sending an idea DIRECTLY to engineers will get your idea to the market faster. That's a win, right? Unfortunately, the old days of celebrating a software launch aren't good enough. Agile engineering is only as good as the ideas being put through it. You should be focused on celebrating at the moment you've made users happy. You wouldn't release financials without an audit. Why would you release software without user testing?

Speed to Product/Market Fit "Instead of Speed to Market, focus on Speed to Product/Market Fit"

Speed forces better decisions

Speed-oriented conversations sound like this.

  • "Let's go with what the users liked the best."
  • "Looks like a toss up, just choose one of the options and go for it."
  • "Which of these design elements takes the longest to build?"
  • "Do users really notice these gradients and elaborate shading?"
  • "What could I cut to get this software delivered faster?"
  • "What's my trade-off to get this delivered in 6 weeks instead of 8 weeks?"
  • "Let's get this out the door and fix that in the next iteration."
  • "I may not know exactly which element moved the dial, but this whole concept user tested so much better that we need to get it out the door NOW."

Perfection-oriented conversations sound like this.

  • "Did you test the color of that button?"
  • "It doesn't look ready to me."
  • "Did you show this to (insert "CEO", "Founder", "the Board" here)?"
  • "It's got to have (insert favorite pet feature here)."
  • "Did you fill out the (insert form name here) form?"
  • "Stop the launch. Not all the features are ready."

Focusing on users' needs builds good habits

HPPO decision making process "Do you practice the HPPO decision making process?"

How can a mere Product Manager counter the desires of his or her boss? Especially if the boss is a founder or CEO. How do you avoid the HPPO decision making process?

Get real insights and data from working with actual users. Focusing on real user needs breaks through seemingly endless back and forth internal arguments. Even the most aggressive of CEOs or bosses will have a hard time going against insights learned in user testing.

Though maybe you haven't yet identified your target users or clients? So you don't have these insights. Or maybe you have a cool technology looking for problem.

You might be suffering from common barriers to user testing.

Stop arguing with each other and start listening to users and clients.

Easier to fix software BEFORE it’s written

Cost of Bugs in development Think of this graph as the "Cost of developing a feature"

In the packaged software world, it's commonly believed that catching a bug in the design phase of the software is 100x cheaper than finding it after you've printed millions of CD-ROMs. (NASA, IBM, and there's a contrarian view too)

This doesn't apply to Internet applications and App development (though Apps have a few more challenges). HOWEVER, you can apply these bug-finding principles to determining the cost of finding useful features in different development phases.

It's probably not 100x worse to find and/or validate a feature AFTER the software has launched but perhaps it's 5x more expensive and certainly slower to get to product/market fit. That lack of speed can give your competition a potential advantage.

AND there's the added bonus that there are no bugs in software that you NEVER write. It's likely that you've removed and/or significantly modified features due to user testing results.

Iterations...not big bangs

Thinking in iterations is easier than obsessing over big bangs. Agile engineering concepts are the most powerful changes to software development ever made. Applying that same iterative philosophy to product management and ideation can make your team better at creating top notch applications.

Engineers break large tasks into 2 week chunks. As a result, engineers release code more often. Bug that do occur tend to be smaller, more understandable and easier to fix.

On the Product side of the house, product managers can take vague ideas and break them into testable chunks. UX Designers can turn ideas into prototypes and get them into user testing in a matter of days. In this fashion, product teams move onto new ideas faster and don't get stuck.

You think you’re alone but you’re not

Assume someone else has already thought of your idea.

Co-invention of jet engine "Co-inventors of the jet engine: Hans von Ohain and Frank Whittle"

Many ideas germinate at the same time. Inventors take advantage of advances in technology. User behavior changes globally and entrepreneurs serve those needs.

The jet engine was invented a continent apart by two individuals at the same time. Other famous inventions happened simultaneously.

My most recent company, PowerReviews and it's #1 competitor (former acquirer as well), Bazaarvoice, were founded within one month of each other...which is why you never brag about the details of your startup to the guy sitting next to you at a random conference while you're still in stealth mode (ask me about this).


Keep reading about how "Agile Engineering is useless..."