Article
Reality Check: Are You Still Designing the Right Product?
Throughout product design, you need to make sure you’re designing the right product at the right time for the right audience to realize ROI. Here’s how.
Product development is risky and expensive. And as a marketing leader, the last thing you want is to release a sub-par product that fails to deliver the ROI you need.
However, you can easily end up launching a market flop if you simply hand your product requirements to your development team hoping they’ll emerge with a stellar design in a year or two. Why? Because product design doesn’t happen in a vacuum. Throughout the development process, a lot can change. New insights may be uncovered, the competitive landscape may shift, user needs may evolve, etc.
1. Are Our Product Requirements Strategic and Flexible?
News flash, your PRD and MRD are not gospel! Yes, they provide important insight into what you’re looking to achieve with your next product. And yes, it’s vital that you clearly communicate your product idea to the development team so they deliver a product that meets your company’s business needs; however, often the best way to arrive at your desired destination is to set your preconceived product requirements aside.
Take PRD and MRD Requirements With a Grain of Salt
Your product development team could fulfill every requirement on a PRD or MRD and still end up with a dud. This happens when:
- The requirements don’t allow room for exploring features and specs that could have a significant positive impact on the product
- The requirements sound good on paper but don’t account for how the product’s features will interact with one another or the overall impact to the product
- Your requirements don’t match up with what users need or want
I observed the impact of following requirements to the letter when I worked in the aerospace industry designing helicopters. At the beginning of a new program, marketing would hand over a stack of requirements that someone would convert into thousands of technical requirements. Then, a team of 350 engineers worked for several years to design an aircraft based on those technical specifications. The problem was the engineers never knew what the marketing requirements were — they just checked off the boxes in front of them.
Without someone to continually evaluate whether the design truly met the overarching marketing objectives, there was a significant risk of designing the wrong thing even if the team met every individual requirement. Additionally, the engineering team rarely felt empowered to push back on requirements that had significant impacts to the overall system. In one example, this resulted in an electrical system architecture that weighed twice what it could have just to meet some low priority marketing requirements. This was eventually identified years into the program when the aircraft’s weight budget was blown and resulted in a costly architecture change.
Conduct a Proper Strategy Phase
To mitigate the risks outlined above, M3 begins the development process by temporarily setting aside the requirements documents and working with our clients to figure out the problem we are truly trying to solve.
This starts in the strategy phase, where we:
- Consider your product idea through the lens of stakeholder-centered design
- Conduct (or review) user research, develop user personas, and engage in journey mapping so we understand the user’s experience with the product
- Develop success drivers to inform the concept/design phase
- Create storyboards and mood boards to ensure we’re moving in the right direction
These exercises enable us to understand the big picture rather than immediately working our way through hundreds of individual requirements. We define the problem, uncover numerous ways to solve that problem, and then narrow our focus to a smaller subset of ideas to test and mock up. And as we go, we continually check our progress against what we learned in the strategy phase in order to stay (or get back) on track. This process allows us to understand and even push back on requirements through the lens of a successful product.
2. Are We Adding Design Features Because We Can or Because We Should?
It’s natural to want to develop a product that impresses and delights your audience. But at the same time, it’s easy to get so caught up in creating a design marvel that you fail to consider whether it’s truly the best solution.
There’s a false but entertaining urban legend about NASA that illustrates this point well. As the story goes, NASA spent millions of dollars to create a space pen that could write in zero gravity, function upside down, and withstand extreme temperatures. Meanwhile, the Russians used a pencil. We laugh at the idea of going to so much trouble to devise an overly complex solution to a simple problem, but the truth is in the era of inexpensive technology (thanks iPhone!) it’s incredibly easy to fall into this trap.
But this tendency exists even in industries involving more complex technology. One of our clients wanted to revolutionize a particularly taxing medical procedure by fully automating the process. We designed a prototype that met this requirement, but it was immediately apparent that the device would be overly complex and prohibitively expensive to produce. After coming to this conclusion, we were able to take a step back to identify which parts of the procedure could remain manual and which would benefit from automation. We ultimately delivered a best-in-class product that delighted operators and met our clients business goals. But we could have achieved that result much sooner, had our client more carefully evaluated their requirements by asking questions like:
- What is the core problem that this requirement aims to solve?
- Does this requirement limit the ways in which the core problem can be solved?
- By making this request, are we enhancing the user experience or distracting from it?
Sometimes the simpler solution is the better one.
3. Have Our Competitors Already Beat Us to Market?
It takes a long time to bring a product to market. A lot can change in the time required to design your ideal solution, develop a prototype, and get the final result into production. So what happens if you’re halfway through development only to discover that a competitor has released a comparable — or better — product?
This exact scenario recently happened to one of our clients. Before we started the project, our client had determined performance specs for their product in a very competitive market. We worked for months to generate concepts that would satisfy these requirements, but in the middle of our development process, their competitor released a product that blew our client’s out of the water. Their first reaction was just to proceed as planned because they feared the cost of taking a step back ). We strongly encouraged them to reconsider. What would be the point of investing even more time and energy into a product that would already be behind the curve upon its release?
Ultimately, we backtracked a bit, but we were able to redesign our product to be a competitive solution for their market. Did it cost valuable time and money? Of course. But it would have certainly cost more to bring a product to market that can’t compete. Redesign is not always the answer either. A situation like this may force you to identify a different market or opportunity for your product. You might discover that adapting your messaging and finding a different way to position your solution is enough to generate the ROI your company requires.
The key is to stop, assess the situation, and pivot as needed rather than doggedly staying on course. This is all part of delivering future-focused solutions that will stand up to the competition over time.
Question, Validate, and Iterate to Achieve Product Success
Product development is a process of learning and discovery. As such, you should not expect — or want — good engineers and designers to simply give you what you ask for.
It’s your job to come up with product ideas based on the market opportunities and gaps you identify. But you can’t know you’re truly designing the right solution unless you ask good questions, challenge and validate your existing assumptions, and unleash the full measure of your team’s creative capabilities.
This can be hard to do without the help of an objective external partner. An outside perspective is often necessary in order to look beyond the initial MRD and PRD and create truly innovative solutions.
We’ve helped countless clients make the market impact they’re after and deliver the ROI they need. We’d love to help you, too. Just reach out.
