What, Not How: Why Creative Requirements Are the Key to Breakthrough Products

When building a new product, especially in the early stages, how you think shapes what you build. And the first mindset shift startups and small businesses must make is this:

Focus on the what, not the how.

At the requirements stage of product development, the goal is not to engineer solutions. It’s to define needs. To zoom out and look at what customers are trying to accomplish, not how we plan to deliver it. When we lock into “how” too early, we shrink our thinking. But when we stay open and creatively define “what” the product must achieve, we unlock innovation, flexibility, and smarter solutions.

Request our free template: Requirements Document Template

This blog unpacks why creative, open-ended requirements are critical for small businesses and startups, and how focusing too early on execution can actually limit the value of the product you’re developing.

The Innovation Trap: Jumping to “How” Too Soon

Let’s say a team building a smart home system says:
“We need to use voice commands to control the lights.”

Sounds like a solid idea, right?

But pause. That’s not a requirement. That’s a solution.
It answers how we’re going to solve a problem, but we haven’t yet clarified what the actual problem is.

A better version of that requirement might be:
“The user must be able to control lighting easily without physical switches.”

Now we’re talking about the what. The actual user need.

Whether that’s through voice, mobile app, gestures, scheduling, or even AI, comes later. When you phrase your requirements in terms of outcomes (what the user needs), you open the door to a wider range of possible, and often better, solutions.

Why “What” Matters So Much in the Requirements Stage

The purpose of the requirements phase is to gather insights, not decisions. It’s where you understand your users, explore goals, and define the problem space.

Here’s why “what” is so powerful at this stage:

• Encourages Creativity: When you’re not tied to a single solution, your team can brainstorm freely. This leads to surprising ideas you wouldn’t reach otherwise.
• Avoids Personal Biases: Founders and engineers often have favorite tools or methods. Focusing on “how” too early can embed these biases before testing whether they’re even appropriate.
• Keeps the Customer Front and Center: Customers don’t care about your backend architecture or your circuit design. They care about whether the product solves their problem efficiently. Requirements should reflect that.
• Increases Agility: If you lock into one path too early, pivoting becomes painful and costly. Staying solution-agnostic gives you room to adapt based on feedback and constraints.

Examples of Good “What” Requirements (And Not-So-Good “How” Ones)

Let’s look at a few examples to make this clearer:

In each case, the “what” describes a business or user need. The “how” assumes a specific solution, one that might work, but might not be the best.

The development budget is the key part of the requirements stage: Product Development Cost Calculator

What Belongs in Requirements (And What Doesn’t)

At this stage, your job is to define what success looks like from the user’s perspective. Here’s how to know what qualifies:

✅ Include These (Creative, Outcome-Driven Requirements)

• “Technicians must track oil levels remotely to avoid on-site inspections.”
• “Users must configure alerts without engineering assistance.”
• “The device must survive outdoor conditions for up to 5 years.”

These are clear, measurable, and linked to real-world needs. They help your team think deeply and creatively.

🚫 Avoid These (Internal or Technical ‘How’ Statements)

• “Use MQTT protocol for device communication.”
• “Design a 4-layer PCB for all modules.”
• “Integrate with XYZ analytics dashboard.”

These may eventually be great solutions, but they’re not requirements. They can be discussed in the design or engineering phase after customer needs are defined.

A Real-World Startup Example

A small agri-tech startup approached us with a request:
“We want to design a drone that uses infrared cameras to check crop health.”

Our first question was: Why infrared cameras?
Their answer: “We heard it’s effective.”

We reframed the requirement:
“The system must detect signs of crop stress early and accurately.”

Now we had a real what. That opened the door to a wide range of possibilities: soil sensors, satellite imagery, machine vision with color detection, drone flyovers, etc. Eventually, we found a hybrid approach that was cheaper, more scalable, and faster to deploy than their original idea.

Important Note: This “What, Not How” Rule Applies Only to the Requirements Stage

Let’s be clear: Once requirements are finalized, the how becomes critically important. That’s when your engineers, designers, and partners figure out the most practical and effective path forward. Technical decisions, design tradeoffs, and optimizations all matter, but only after the right requirements are in place.

Think of it as a relay race. The “what” team sets the direction. The “how” team delivers the results.

Whenever creating the requirements, it’s always key to keep the ROI in mind: Product Development ROI Calculator

Conclusion: Don’t Lock the Door Before You Look Outside

In the rush to get products to market, it’s tempting to solve problems as soon as we hear them. But that instinct can limit the very innovation you’re chasing.

If you’re a startup or small business developing a new product, give your requirements room to breathe. Stay focused on what your customers actually need. Let creativity and insights flourish before locking in solutions.

Because the most successful products aren’t just built, they’re thoughtfully imagined from the ground up.