From Idea to Startup (Pt. 2/5): Validate Your Business Idea

Key Takeaways:

  1. Avoid pursuing ideas based on false assumptions by gathering data about their desirability, feasibility and viability first.
  2. Start by testing your idea’s desirability and understanding your target customers’ needs better with empirical customer discovery.
  3. Be willing to pivot if the customer feedback suggests your idea doesn’t solve a significant problem.
  4. Then analyze the feasibility of your idea from technical, legal, and operational views.
  5. Finally, determine the viability of your idea by validating its financials through a solid business case.
  6. Use our practical checklist so you don’t miss any critical steps as you validate your business ideas.

Are you ready to turn your business idea into reality, but not sure if it will fly? Before you take the leap, make sure to vet your idea critically from all sides to avoid a crash landing.

In this article of the “From Idea to Startup” series (click on the image to view all articles), we delve into the crucial role of validating your business ideas before making any significant investments. We’ll guide you through the process, covering all key aspects such as customer discovery, technical feasibility analysis, and the dreaded “business case”. At the end of this article, as a treat, you’ll find a hands-on checklist summarizing all key topics for your business idea validation.

Note that the principles outlined in this series of articles are useful for both start-up entrepreneurs and corporate intrapreneurs.

Validate Your Idea’s Desirability for Customers

Understanding the needs and solving a concrete problem of your target customers is the starting point of any successful product development.

To validate your idea’s desirability from a user view [general note: I use the terms “user” and “customer” interchangeably and even if it makes this article sound software-heavy, its principles apply to traditional businesses, too.] there is no way around empirical customer discovery. This is the systematic gathering of data about your potential users via interviews, surveys and tests to better understand what they need and to get feedback for your product.

Unfortunately, we’re naturally inclined to neglect this important aspect of idea validation due to the “false consensus bias” which is a bias which seduces us to believe ours share our opinions, beliefs and values. We must resist the temptation and talk to our customers to avoid developing what nobody but ourselves wants.

First, clearly determine your target customer segment and invite a small group of test users to test your MVP (minimum viable product). If you’re still at “idea stage” it is also perfectly fine to just interview them about what they need and the challenges they face with existing solutions. This pushes you a bit out of your comfort zone but ultimately gives you the needed insights into how your idea/product performs “in reality” and then use the feedback to improve it.

It’s important not to “forget” testing the willingness-to-pay (WTP) for your product during the customer discovery process (even though it can be the most uncomfortable assumption to test – since it’s so revealing). You’ll need this information to determine whether there is a “market” (paying customer base) for your idea, and to make a solid business case, i.e., validate the financial viability of your idea.

Often, it’s tricky to ask for their WTP (#incentives): Sometimes it can work to just ask directly, sometimes you need to do it smarter, e.g., with A/B tests of MVPs at different price points, pre-order campaigns etc. or other best practices you should check out in advance.

There are many ways to find test users like dedicated recruiting platforms, recruiting posts on social media, asking colleagues, friends and family etc. Mind your test users’ motivation though; friends and family may not tell you what you need to hear but what they think you want to hear to not hurt your feelings. It may be better to go with users who you’re not too closely related to, and to proactively encourage them to be blatantly honest.             

User interviews are an art and a “101” would be beyond this article’s scope (so consider extra research). However, there are best practices I want to share with you. Firstly, listen more than you talk, and ask open, non-leading questions: It’s not about convincing them of your “great idea”. You’re there to learn about their needs and how they view your idea – as (painfully) truthfully as possible. Secondly, be willing to pivot (i.e., change ideas), if feedback suggests your idea doesn’t meet their needs.  

Capture Customer Requirements “Problem-First”

As you proceed with your empirical customer discovery and gain a deeper understanding of your customers’ needs, you should capture these requirements in a clear and concise way. One tool I like to use for that are “user stories”.

These are succinct, user-centric descriptions of the functionalities you build into your solution to address your users’ needs. User stories are typically formulated like this: “As a [user role, e.g., “cheese shopper”] I want to [requirement] so that [intended user benefit]”. Of course, you don’t have to blindly adhere to this “formula” – just make sure you somehow capture the key points. Focusing on the benefits of each feature ensures you’re not building functionalities “in a vacuum” or because “you always did it that way” etc. Instead, every feature has its purpose, i.e., create customer value, and waste gets reduced.

User stories also help avoid “implementation bias”, i.e. our tendency to jump to nitty-gritty implementation details too quickly. It’s key to resist that urge and clearly define the “what” and “why” of your user stories first, and then let your technical experts figure out the “how”. For example, instead of specifying how the functionality should be implemented (e.g., “users must be able to find cheese products in our web shop with a search bar”), focus on the desired outcomes (e.g., “users must be able to quickly find any cheese they want”).

This gives your technical experts the freedom to develop the best solutions and everyone to operate in their sweet spot. As an entrepreneur, your job is to perceive and seize opportunities, and orchestrate complementary capabilities to make it happen; there’s no need to be a one-(wo)man-show.

Here again “customer journeys” are great and enable 3 things (by mapping user stories or activities from left to right): Firstly, we can test for completeness, i.e., if we gathered all user stories we need to create the intended customer experience. Secondly, this “process view” gives us deeper insights into potential pain points or areas for improvement. Thirdly, it allows us to develop “lean” MVPs: We can create simplified versions of our final product by “implementing” only one particular path through the journey (while neglecting all branches).

This way we can efficiently gather feedback for the core value proposition. For example, imagine building a make-shift stand to test only the signature lemonade instead of directly launching the full-blown bar with all offerings. If they don’t even want our core product – why even bother with the rest?

Talk is silver, show is gold“: it’s easy to talk past each other, and observing users interact with your product provides rich, non-verbal feedback. To really understand your users’ needs – i.e., see when they look delighted or frustrated, when something does or doesn’t work as intended etc.- it’s key to make your idea tangible and experiential ASAP. Start with simple sketches, interactive PowerPoint slides that serve as the user interface (UI) for an app, and then gradually transform them into the product you envisioned – one (feedback) loop at a time.

Eventually, you should collect all the customer requirements you elicit in a “user requirements specification” (in “traditional words”) or (in “agile terms”) a “product backlog”. This central repository gives you a concise and clear overview of all the functionalities your product or service should achieve and is the basis for planning the implementation work, and finally working the plan (iteratively).

Validate Your Idea’s Technical Feasibility and Business Case

Another cornerstone of validating our business ideas’ success potential is its so-called “techno-economic assessment”. Specifically, this “big word” just means analyzing the technical feasibility and financial/business viability of your business idea.

Even though these two topics look disparate at first and require different skills, they are highly interdependent which is why I merged them in one chapter. This also shows how important it is to work closely in cross-disciplinary teams, e.g., by combining “expertise in human nature” (i.e., marketeers or psychologists) with tech and financial whizzes to create innovations that tick all three boxes (desirability, viability and feasibility).

Before we jump into the ins and outs of techno-economic analyses, let’s briefly recap what we did in the “idea validation stage”: Firstly, we talked about the key role of empirical customer discovery to really grasp our potential customers’ needs. Secondly, we discussed how to translate or specify these customer requirements as concise user stories. With this solid basis, let’s now dive deeper, first into the technical and second the economic analysis.

The technical feasibility study is all about getting a clear understanding of the technical requirements of our business idea. It answers the question whether your product idea can be reasonably “brought to life” (i.e., developed and marketed) with the available technologies and resources (constraints).

Technical requirements are basically all the technologies (hardware, software, connectivity etc.) you need for your idea to fly. They have many faces: there are functional requirements (e.g., to provide specific functions like in the user stories) and non-functional ones like ensuring sufficient performance, speed, security, scalability etc. For example, a smartphone app has other technical requirements than hardware like a smart home gadget etc.

It’s crucial to look at the whole “life cycle” of your product in this analysis, i.e., from its design to development to implementation since each stage can introduce further requirements. These requirements then inform the design of the product and business operations (and vice versa!).

Now, let’s dive into the financial analysis, also called “business case” in corporate lingo. This is about validating the business potential of and needed capital/money for your idea. That means we want to figure out whether it’s “worth it” and we have the resources to get our product to the market and sustain it.

For that, we must determine the costs of the resources (tech, staff, materials etc.) we need to start and run our business, and then compare these with the revenues we expect to generate. A straightforward approach to elicit costs is to check or ask potential suppliers for prices. Regarding revenues, you can, for example, apply market sizing techniques like in this article and test the WTP during customer discovery.

We want to test three things with this type of analysis: Firstly, if our idea becomes “profitable” (i.e., periodic revenues > costs) soon enough. Secondly, we want to figure out whether we can collect/set aside enough money for our business to survive until it becomes profitable and “sustains itself”. Thirdly, we want to know whether the profits meet the expectations of our investors (or ourselves) so they actually invest.

The latter is highly subjective and will be covered in-depth in another article about startup finance (incl. a more detailed look into business case calculations), but as a ballpark figure: Venture capitalists typically expect at least “to 10x” their investment over 5-10 years.

Validate Your Idea’s Legal and Operational Feasibility

Another area which is often overlooked (especially by first-time entrepreneurs) – because it’s not as glamorous as big money and high tech – are the legal and operational requirements of your business. However, you want to ensure your idea is compliant with relevant regulations, and there are no operational “bumps” on the road that prevent your business from taking off or cause avoidable turbulences or even an emergency landing.

From a legal perspective, some areas to check (and potentially discuss with a lawyer) are…

  • picking the “proper” (given your goals and risk appetite) business structure (which has implications for taxes, profit distribution and liability etc.),
  • officially registering your business,
  • checking for and obtaining required permits or licenses,
  • “the intellectual property (IP) situation” (patents, trademarks, copyright etc.), i.e., checking whether you infringe others’ IP or to protect yours.
  • further (industry-specific) regulations, e.g., regarding health and safety or data protection.

Operationally, you want to understand the required “logistics” of starting and running your business as intended, and check whether that’s “doable”. This means (literally) “listing” all (important) resources (time, employees, technology/equipment and materials etc.) and partners or suppliers your business operations need to run (efficiently).

Research shows a key driver of long-term success is process-like thinking: Determining the status quo, visioning the target state, mapping alternative paths step-by-step from A to B incl. their resp. opportunities and roadblocks, prioritizing, while moving ahead swiftly. Think like an architect in processes, systems, structures: Map them – literally with (digital) pen and whiteboard – and make the machinery (i.e., your “operating model”) consistent.

Overall, it’s crucial to emphasize how closely intertwined all these analyses (use case, technical, financial etc.) are: For example, the requirements of our customers from customer discovery and legal ones inform the design of our product and operations we must put in place to provide that product. The use case, legal and operational requirements inform which resources (incl. tech) we need aka our idea’s technical requirements. The resource requirements then determine our cost projections etc.

Never run these analyses in isolation but rather try parallelizing them as much as possible as they inform each other. Parallelization is generally king in product development as it allows you to build your product in a faster, cheaper and more integrative way.

Bringing it All Together: Your Checklist for Idea Validation

To successfully launch your business, it’s crucial to vet your idea from all angles, incl. customer desirability, technical feasibility, and economic viability. By adopting a user-centric approach and iteratively gathering feedback in short cycles, you can validate your core assumptions, reduce risks, and create a product that truly benefits all stakeholders.

If your idea fails any of these “tests,” don’t be afraid to pivot and “kill your darlings”. Don’t fall for the cognitive bias “escalating commitment”, i.e., our tendency to continue investing in failing projects due to sunk costs or pride. Avoid throwing good money and time after bad: better an end with horror than horror without end.

Refer to our handy checklist below as you validate your business ideas:

  1.  Customer use case:
    • Identify the problem and understand the customer’s needs and pain points
    • Specify the requirements for a (rel. better) solution with potential customers
    • (Iteratively) test acceptance of (and WTP for) your solution with MVPs
  2.  Technical feasibility:
    • Derive important functional technical requirements (esp. from user stories)
    • Identify key non-functional requirements (performance, security, scalability etc.)
    • Assess the availability of the required technology and resources
  3. Business case:
    • Determine the costs by “checking the price tag” of the resources you need
    • Assess the revenues, profits (and further metrics of interest)
    • Evaluate the availability of the required funding/financing
  4. Legal matters:
    • Ensure compliance with all relevant laws and regulations
    • Obtain necessary licenses and permits, consider IP, and register your business
    • If in doubt, consult a lawyer
  5. Operating model:
    • Map out the needed logistics and supply chain of your business
    • Determine the resource (and partner) requirements and availability
    • Consider your product’s entire life cycle from idea to development to daily business

Please share your feedback in the comments or forums so we can all learn from each other and grow together with entrepreneurial creativity. I wish you success in testing your business ideas and turning your vision into reality.

In this series’ next article, we dive into the vital task of bringing all of these strings (and more) together in a coherent business plan for strategic clarity and to convince investors.

Cheers, John.

Recommended Resources for the Go-Getters

Here are some resources for the hungry ones to dive deeper into today’s topics:

  • “The Lean Startup” by Eric Ries – This book offers a comprehensive, tried and tested framework (“lean methodology”) from generating new product ideas to building, testing, launching and scaling them with fast feedback cycles.
  • “The Mom Test” by Rob Fitzpatrick – This is a useful guide for everyone who wants to learn how to get honest feedback from test users, even when they’re not incentivized to tell you the truth, e.g., regarding their WTP.
  • “Zero to One” by Peter Thiel – This “classic” of the startup scene offers practical insights into developing a creative and visionary approach to business, allowing you to spot and seize untapped opportunities.
  • “Business Model Generation” by Alexander Osterwalder and Yves Pigneur – This hands-on book uses a handy canvas to guide you in a visually appealing way through all relevant dimensions of your idea’s business model, from its value proposition to its revenue models.

Share your thoughts