Founders, if you want A+ startup success, do the homework first!

The problem with problems

When founders lean too heavily on their strengths, blind spots emerge. For instance, technical founders often dive straight into coding, thrilled by the prospect of building something new, while neglecting to validate if their solution fits real user needs. Meanwhile, business-minded founders might get caught up in perfecting marketing messages or brand positioning, stalling actual product development.

Both paths miss the mark-whether it’s building the wrong thing too quickly or planning the perfect launch for a product that doesn’t yet exist.

Irina Nazarova CEO at Evil Martians

Schedule call

The antidote to these tendencies is simple but powerful: keep your eyes firmly on the problem you’re solving. Marc Laventure, CEO & Co-Founder at Scalar shared with Evil Martians: “success comes from building stuff people love” and providing upfront value. This focus helps cut through both the technical excitement and the marketing noise.

But knowing the problem isn’t enough-you also need to deeply understand who you’re solving it for.

Understanding your users

Your target customer isn’t just a market segment; they’re real people with specific needs, habits, and pain points. As Nikita Shamgunov, CEO of Neon, noted in this episode of our podcast Dev Propulsion Labs, the customer you’re pursuing becomes part of your company’s architecture-it affects everything from your technology choices to the team you build.

Understanding your users-what makes them tick, how they work, and what frustrates them-becomes your compass for every decision.

Let’s talk about how to get started understanding your users.

Conduct a round of customer discovery. Stefan Avram, Co-founder at Wundergraph shared on this episode of our podcast, the book, “The Mom Test”, provides an excellent framework for this: focus on understanding how users currently solve their problems rather than pitching your solution; this helps validate whether you’re addressing real needs or just surface-level complaints.

Second, you can also conduct a competitive analysis to understand the strong and weak aspects of existing rival solutions.

You’ve done the interviews and research. Now what?

After conducting all of your interviews, reflect on them, and then drill into that one small problem that you really, really have a desire to solve.

Many of the world’s biggest companies started off by solving a small problem for a specific niche.

As an example, look at New Relic. It initially offered a single product for Ruby on Rails application performance monitoring and now their tech ecosystem offers a full observability platform and every single type of monitoring one could ever need.

Put your homework in writing: the problem-audience statement

Once you have a problem and the audience figured out, we recommend actually writing down the problem and target audience definitions on paper.

These factors influence each other, so it’s crucial to have them written down and always keep them in front of the eyes.

This physical statement will help you and your team maintain the proper focus. Think about this: when you discuss your product, reasonable feedback and new ideas will always be put forth. Your main task is to ensure that focus remains on what matters to your target audience. Your problem-audience statement will help you to maintain that focus; everything else is a good candidate for the backlog.

Craft a vision of how your product will handle the problem better

Now, consider the unique value your product will offer and how it will differentiate itself in the market. And this isn’t solely about making a faster product or something more feature-rich.

It might seem unnecessary to formally craft a product vision at an early stage. (After all, founders certainly have their own set of ideas about solving a problem.) Thus, an informal founder’s vision might seem like it’s all that’s needed.

However, two things are usually required to really achieve a founder’s vision:

• Stakeholders (employees, consultants, investors, and so on)
• Customers

So, if the vision underlying your solution is locked away in a founder’s head, and potentially quite vague, realizing this dream is going to be a much taller order.

Creating a formalized product vision might take some time, but it’s worth it!

Make a list of assumptions to validate

Create a list of assumptions about your product. These are all the things you believe you know but don’t have tangible evidence to support. Let’s say you’re making an IDE to re-imagine the future of team programming. Your assumptions might relate to:

• Market demand for such a solution
• User willingness to use it
• Your ability to provide a better experience than existing alternatives

We recommend treating the first version of your product as a kind of experiment to validate these assumptions. Sometimes, challenging these assumptions leads to breakthroughs-like how Docker revolutionized virtualization performance by questioning whether containers really couldn’t share the host system’s kernel and resources.

Testing your assumptions

From there, formulate hypotheses to challenge your assumptions. These hypotheses must be exact, measurable, and testable. For our IDE example, a hypothesis might be:

“At least 20% of frontend engineers who visit our landing page will sign up for our IDE.”

This hypothesis is specific enough because it defines the target audience, the action, and the metric. You can use industry benchmarks to state success criteria for your hypotheses.

Working with design partners: considering your options

The conventional startup wisdom suggests finding design partners-early users who provide feedback on your solution. While this can work, it’s worth considering alternatives based on your market and product.

When seeking feedback, you have several paths. You might post on Bluesky, X, LinkedIn, Reddit, or do cold outreach to experts. If you have investors, their network can be valuable, especially for enterprise solutions. Landing pages and ads can also attract potential early adopters.

Consider Trieve’s experience, shared by Federico Chávez-Torres, Growth: instead of traditional design partnerships, they opted for paid proof-of-concepts at $500 with clear success metrics. This approach created proper customer-client relationships from day one, ensuring both sides were invested in the outcome.

If you do choose the design partner route, start small. Five high-quality partners are usually enough for testing specific features or personas. For broader products, like analytics tools, you might need partners from different industries-but remember that more partners mean more expectations to manage.

The key is making these relationships productive, whether they’re design partnerships or paid engagements. Set clear expectations, define success metrics upfront, and establish regular feedback cycles.

Your homework is nearly finished

When you have a clear vision, assumptions to validate, and design partners ready to work with you, that’s awesome. But… it’s still not time to dive into implementation.

First, you have one final assignment to work through: define and prioritize the product features required for testing your assumptions and delivering value to users. We recommend focusing on a simple but effective solution balancing between a prototype and a full-fledged product.

Defining your first features

When defining your first features, start with your core functionality-the features that directly solve your users’ major problems or help validate your key assumptions. For an enterprise anti-phishing system, this might mean focusing on:

• The phishing detection algorithm
• Attack reports
• Essential user management

From there, maintain a smooth user experience without getting caught up in fancy animations or nice-to-have features. Finally, be ruthless about scope-if you’re building an infrastructure audit platform, save the automated cloud migration feature for later versions.

Class dismissed!

And now, we’re here. It’s time! With all this in mind, here’s some final advice before leaping in: focus on a simple solution rather than making the next GitHub or Visual Studio Code.

And a parting thought: the first version of your product is not about perfection, it’s about learning, iterating, and adapting. Good luck!