3 Keys To Feature Validation
We've learned that customers have a problem. Product managers document the problem in a product story and designers reply with a prototype of spec. (Remember, product managers are expert in problems; designers are experts in solutions.) But wait! Don’t write that code yet. You’ll need to validate the proposed solution before you start developing it.How do you make sure you’re building the right thing? Use these three techniques for feature validation.
Clarify the business rules
Where development (and feature validation) tend to go awry is when you’re not quite sure what problem you’re solving. Before prototyping, discuss the market problem with your team and be clear on the business rules: What are the needs? What are the constraints? What are the outcomes?
Needs, constraints, and outcomes are the basis of acceptance testing. Clarifying these will guide the design of the prototype or feature. Does the prototype or feature do what it should? Will it deliver the desired outcome?
For example, a system like Eventbrite has a need: Support multi-user registration for public events using a single payment. Person making payment may or may not be a participant. And a constraint might be: “Each participant must confirm their email before they can attend a public workshop.” Ultimately the outcome is “The system handles all the mechanics of the webinar so we don’t have to.”
These business rules—call them stories or requirements or whatever—define the parameters of successful implementation. They’re not stress tests; they’re not implementation specifications. They are the guide to determining whether the feature does what it needs to do.
Use “hallway usability testing”
Feature validation doesn’t have to be a massive effort. As soon as you see a prototype, you may immediately like the implementation. After all, you’re a customer representative. But if you’re not sure, show it to some friendly colleagues and customers.
Back in 2000, Joel Spolky wrote The Joel Test: 12 Steps to Better Code. The final step is “Do you do hallway usability testing?”
A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.
I’d recommend you test the idea on non-developers; after all, developers have a knack for using even the most convoluted solutions because they understand the underlying infrastructure or mental model.
Test your proposed solution with some nearby buddies—especially those who best represent your user personas. Show it to your favorite sales people, support teams, and marketing folks. This can be done in a matter of minutes; it doesn’t have to be a protracted process.
Share prototypes with key clients
In your customer discovery, you should have built a few friendships with your customers. People you’ve learned to respect. Give them a call and describe what you’re planning to build. Set up a screen sharing session and show them the prototype. Listen to their feedback and write down every sentence that starts with “Will it…?” or “Can it…?” or “I thought it would…” (and especially, "Hmm, that's interesting.")
It’s critical to do validation with people you trust. Clients who won’t share your ideas with competitors (or even with your sales people). Clients who won’t mandate a deliverable based on what they’ve seen. After all, you don’t want them blogging about it or making it a contractual commitment. Remember: a prototype may never be built. It’s a representation of an idea that may not be delivered.
Show the feature to three people
As a product manager, you’re a market representative. You’re expert on the market full of customers. You’re an expert on problems. You’re expert on the business rules, not the implementation. Your designers and developers are expert on solutions. Give them a problem and let them guide the solution.
You should be able to validate a feature in just a few hours. Share the design with three people: yourself, at least one company colleague, and at least one friendly customer. Golly, you can do that by the end of the day.