Do the Hard Work Upfront
One of the biggest mistakes we see with new product ideas is that founders come to us with a solution already fully formed in their minds. While well-intentioned, this can set the project up for failure. We can design the best widget in the world, but if it does not solve the problem (or the problem is not worth solving), it doesn’t matter.
This can cause otherwise positive engagements to end on a sour note. The client loves the product that was designed and prototyped, but it flops in the market, or it doesn’t truly solve the problem, and they’re left wondering why they spent all that money in the first place.
As a product development firm, we have an obligation to diagnose before prescribing. Our key value-add is not just the product itself, but the process we use to arrive at the right product. At Pillar, we frequently work with founders developing hardware for the first time. This is a significant endeavor to undertake, and clients can sometimes be surprised by the level of investment, time, and iteration required to bring a product to market.
The most successful engagements we’ve had are the ones where we spend significant time and energy upfront properly defining the problem, the solution, and the specific requirements of the product. So, what does this process look like in practice?
Typically, this work takes shape as a market requirements document (MRD) and a product requirements document (PRD).
The MRD defines why a product should be built. It focuses on the market need. It helps define the user, the problem, the competitive landscape, and the business rationale for the product.
The PRD defines what to build. It translates the MRD into specific product requirements, features, constraints, and success criteria.
There is also an engineering requirements document (ERD) that follows the PRD. It defines how the product will be engineered to meet the PRD, but that’s an article for another day.
It’s not so much about the content of the MRD and PRD themselves. They’re not set in stone and will often change as development progresses. It’s the act of thinking through the right questions and planning early. That is what surfaces critical assumptions, missing requirements, and hidden risks before they become expensive problems.
Ideally, all this work should happen before a single sketch is drawn or anyone fires up SolidWorks.
Of course, this process can go too far. Not every project needs a massive amount of documentation or a 6-month discovery process. This kind of upfront work can easily cross into “process theater” if it’s not grounded in the actual needs of the project. The right level of rigor depends on the complexity of the product, the level of technical risk, and the cost of being wrong. A simple product with known constraints may only need a lightweight version of this process. A complex product with meaningful technical, financial, or market risk likely requires much more rigor upfront.
Here are some initial questions to ask yourself:
- What problem are we actually trying to solve?
- Why does the problem exist?
- Who has this problem?
- How are they solving it today?
- Are the existing solutions insufficient, or are we just excited about building something new?
- Is this a real market opportunity, or just an interesting idea?
- Does the budget, timeline, and appetite for risk align with what it will actually take to bring this product to market?
- What does the product need to do to solve that problem successfully?
To summarize: if you’re looking to work with an outside product development firm, engage them early and spend the time and money upfront to thoroughly define the problem, solution, and product requirements. A good firm should challenge your assumptions and guide you through that process.
The cost of this upfront work is small compared to the risk of spending far more time and money building the wrong product.
