Having worked in product development and consulting for years, here’s the one thing all the clients I’ve worked with have had in common: No one really knows how to make products.
Sure, there are companies that can “make” a product. They can put together a set of requirements, design them, and implement them. They can get the product into their customer’s hands, then update it over time. And they can do this over and over with different products. But the problem isn’t making the product. The problem is making the right product.
Most companies struggle with this. Even worse, they might not even realize this is a problem they struggle with. Markets are so self-referential that often times product development seems stupidly simple: just look at what everyone else is making and make it better. Make it smaller. Or bigger. Or Faster. Oh, and definitely, make it easier to use.
How about making something significantly different? Well, no. There’s too much at stake. Companies don’t want to risk deviating too far from the rest of the industry. There’s so much pressure around market share that any potential for innovation is tempered by a fear of alienating existing customers. So at best, products evolve incrementally and predicate on precedent. The idea is to keep it the same but to make it better, somehow.
This usually means just adding new features. It’s the “now with” approach. “Now with… custom profiles!” “Favorites list!” “Nicer-looking buttons!”
By the time anyone gets any input from the customers that will use the product, it’s already too late. They’re picking between features that don’t really add any value for them (“Yeah, maybe I could see myself using that”), and the product is already halfway through production. But no one bothered to check what these users really needed in the first place. And in the end, all the extra bloat just makes the product more complicated and harder to use and your company doesn’t actually see the sales they were expecting. The product lost focus, and so did the team behind it.
But it doesn’t have to be this way.
Design your product from the ground up. This doesn’t mean you need to start over. Just take a step back and take a deep breath. Reevaluate. You can reduce risk by figuring out what truly matters early in the process, directly from those who will be using your product. This should be your guiding light and driving force for product development. You can combat product bloat and entrenchment to come out with something that’s feature-lean but still checks all the right boxes. The best part is, it’s really easy and inexpensive to do. And when properly integrated into the development process, you should be able to ship your product just as quickly.
Start by talking to your product’s users
It’s hard for a product team not to have assumptions. Everyone’s got an opinion because everyone’s an expert at something. Marketing, sales, engineering, designers, customer support—they all have ideas for how to improve the product. And putting all of our ideas together could make it seem like we’ve pieced a full picture of what the user needs. But not really.
Just go out and talk to your users.
This is known as user or design research. But it’s not user testing, necessarily. Testing implies you have something to test. At this point, you need to evaluate your customer’s needs. This is more qualitative. What do they need to accomplish? What’s preventing them from accomplishing this? How are they overcoming this currently? What are their pain points?
Product managers, sales, and customer support reps should be doing some version of this already. They’ll talk to some of their customers who’ll comment on one thing or another. Feature requests. Praises. Complaints. The problem with this approach is there’s no structure. We need a formal process. Consistency. A way to categorize and compare feedback. This is the tipping point between a passive and an active feedback system. And then and there, a lot of companies will stall. It sounds like a lot of work, doesn’t it? It really isn’t.
Start by talking to just four users.
That’s less than half a day if you keep your one-on-one sessions to just under an hour. And sometimes, fifteen minutes is all you need. You’ll be surprised how much you’ll get out of so little.
This one time, a client humored me when I asked if we should go out to talk to some users before we sat down to design their product. This software would help technicians install equipment to monitor flow activity in drainage systems. The client assured me they knew who their users were and what they needed. Still, they saw the value in having my team go out and observe the installation process first-hand so we could understand it better.
Well, out of the first four users we spoke with, two had no idea what they were doing. We later realized the actual job of installing these instruments wasn’t always the responsibility of who the client thought their user was. Instead, it often fell in the lap of employees who had little-to-no experience in this field. For some, this was their first time using a computer. We had to significantly restructure the product to account for these use cases. We prioritized ease of use, tucked away the expert features, and built a lot of instructional material and contextual help into the product: it became a much better user experience. None of our client’s competitors were doing this, so it became a clear point of differentiation.
If you come back from research with completely different responses, like we did, you might have to dig deeper. If you talked to four users, talk to four more. See if you can identify multiple user groups, or types, and plan to talk to four of each. Or six. Or eight. Pretty soon you’ll know your user base inside out.
So what should you talk about?
Don’t just ask customers what they want
There’s an infamous quote out there that is erroneously attributed to Henry Ford: “If I’d asked people what they wanted, they would have said faster horses.” Whoever said it captured the sentiment perfectly: customers aren’t product-makers. They’re not designers. Asking them what they want is a bad idea.
Instead, ask them what they need.
Specifically, ask your product’s users what they’re trying to accomplish and why. Especially the why. There’s a lot of insight and nuance that will emerge if you get to the bottom of it.
“I need to get places quick” — yeah, that could be fixed with a faster horse. Or Ford’s Model T. Or teleportation, as well. But why are your users in such hurry? Maybe it’s because they’re always late. And why is that? If it’s because they’re absent-minded, a schedule manager that sends them reminders to leave early might be helpful. If instead it’s because they often get stuck in traffic, a navigation feature that calculates the fastest routes for them would be valuable. Maybe they’re late because they have trouble picking an outfit. So this could be some sort of smart closet organizer. Or an app where your friends pick your socks for you. If we’d asked Ford instead of the customers, we might’ve ended up with a car.
Knowing what the right problems are is the first step towards trying to design the right product that will address them.
Talk to your users about how they currently get or try to get things done. Put together a discussion guide to get started. Ask about their workflow. Have them demonstrate it for you, whether they’re using your product or not. Go sit next to them, or use Skype, or GoToMeeting. Pay attention to the things they struggle with. The things they like, and why they like them. Ask questions—a lot of questions. Dig deep. And take notes!
Redefine and refine your product’s vision
When you look through and analyze your notes, you will inevitably find patterns. I used to design laboratory equipment. It was clear as day: small and large labs had completely different behaviors and needs, but they were fairly similar within their own groups. Same with hospital labs vs. private labs. Hematology vs. microbiology. North America vs. Europe. Some of these differing needs could be complementary; others, diametrically opposed.
You can’t be everything to everyone. That’s a surefire path to product bloat, and that’s if it’s even possible to reconcile everyone’s needs. Deciding which users’ needs to prioritize will be the first test of your project’s initial business objectives.
Everything lines up perfectly? That’s awesome! Get cracking. But, this won’t usually be the case. Maybe you’ve uncovered some new opportunities or realize that you under or overestimated the potential fit or value of your ideas.
You’ll need to shift gears, reevaluate your plan, and collect further feedback.
Lean requirements and rapid prototyping are a great way to get the ball rolling. Figure out the core components and functions you think are needed to satisfy your primary business objectives, then layer on the critical insights you found from your user research. Keep it lean and trim: you’ll find out fairly quickly if anything is missing, and it’s really easy to add things later.
This is your first pass at a minimum viable product.
Now go back out and test it.
Get feedback as early as possible
Testing early is the key to mitigating risk. You get to see if your ideas work without having to spend too many resources to fully implement them. You can also go out with completely different approaches to your product to help pinpoint the best direction to move forward with (“should our interface be dumbed down or do users want the expert features?”). And if none of them work, you’ll be able to go back to the drawing board knowing exactly why your ideas failed.
You don’t need much to collect this kind of feedback, just something that can let your customers visualize or even interact with key aspects of your product or idea. I’ve done concept testing for digital products with elaborate functional interactive prototypes, and I’ve also done it with a handful of printouts with scribbled drawings that represented the experience of using a product. These drawings didn’t even have any products on them.
The level of fidelity of the ideas you represent should depend on the types of questions you have. Go for a detailed prototype if your product vision is clear and aligned with your user’s needs. This is also a great way to get everyone, including stakeholders, excited about the product. But if you feel you don’t have all the answers just yet, much lower fidelity mockups such as wireframes (drawings of screen layouts) will get you out designing, testing, and iterating much quicker.
Regardless of the level of your prototype’s fidelity, the discussions should still be very qualitative. The process is fairly similar to the user research before (even down to how many people to talk to), except here we want our users to share with us their thoughts on the intended functionality of our product. Does this work for their needs? Does this fit their workflow? Do our ideas provide any value?
If they don’t, tweak them until they do.
Keep validating throughout design and development
Now that you know what you should be doing, and you’ve started doing it, you need to make sure you’re doing it right. If the devil is in the details, this is where you’ll smoke him out.
There’s a lot of nuance in how a product actually works, and more so for digital products. Is the navigation clear? Would a user know how to use all these features? How about finding them? If left unchecked, a lot of these issues might come back to haunt you right after a product’s release. They’ll clog up the customer support lines and will eventually become a challenge to fix without disrupting the original product too much. And until that happens, your customers are ultimately using a product that is broken. That’s bad user experience.
You can run usability tests throughout your development process to resolve most issues before a product is released. Usability testing basically involves a user trying to use your product and either failing or succeeding. Because this type of testing is so tactical, it’s easy to run in between or during sprints by testing only a couple features and tasks.
Designate a test day.
Use this as a sanity check. Run a couple users through a semi-guided discussion where you ask them to perform different tasks. Whenever and wherever they struggle, ask why they think that was problematic for them. Then debrief with the team and figure out if you need to change anything.
Because you’re ironing out the kinks at this point, there’s no reason why you couldn’t run usability testing without being slowed down.
Then do it again and again
With the right structure in place, a “design-from-the-ground-up” approach could prove invaluable. It’s a great way to forge a path forward under uncertainty, or to validate any existing ideas that your product team might have. Having a consistently vetted product development process will also lead to more hits than misses.
And this feedback system gets better over time. It gets easier to engage customers and quicker to get what you need from them. You’ll also progressively become more familiarized with your users, so your team will be much more focused and their wheels will be spinning less. You’ll also find that you’ll spend less time wondering what users need and more time coming up with solutions for them that will be on-point and highly valued.
So design your product from the ground up. It’ll be hard to justify not to.
