The Costly Confusion

What does true validation look like? How do you know when you've genuinely validated your product, feature, or business opportunity?

Over the years I have observed countless product teams and entrepreneurs celebrating user feedback as "validation," only to discover months and millions of rands later that they built something nobody wanted. This common misconception leads to wasted resources, failed products, and frustrated teams.

Validation should never be an elusive destination where team members don't recognize what it looks like, when they're approaching it, or which signs indicate they're on the right path. Instead, it should be a deliberate journey with clear milestones and a definitive endpoint.

Defining the Difference

The distinction between feedback and validation is crucial yet frequently misunderstood:

Feedback

• Is information that has not been processed or interpreted. It represents raw data in the form of opinions, preferences, and reactions to how people experience a product or service.

• It's reactive, that is people respond to something you've already conceptualized or created.

Validation,

• Is a systematic process of verifying whether a product will solve an existing problem adequately enough for people to pay for it and for a sustainable business to be built around it.

• It is a proactive framework where you gather measurable proof that confirms or refutes specific business hypotheses about user behavior, market demand, and willingness to adopt.

The simplest way to understand the distinction:

• Feedback is an input – a data point collected along the journey

• Validation is a process – the entire journey with a clear destination and a map

This distinction isn't merely semantic. It fundamentally changes how you evaluate product viability.

Why This Distinction Matters

The implications of this distinction go far beyond semantics. In my work with both startups and enterprise clients, I have seen how confusing feedback for validation leads to:

• Building features nobody wants

• Extending development timelines unnecessarily

• Misallocating valuable engineering resources

• Making critical business decisions based on insufficient evidence

CLASSIC EXAMPLE: You collect enthusiastic feedback on a new product from various focus groups. Based on this "validation," you decide to invest 18 months in development. After launch, actual usage is minimal. What you had was positive feedback on a concept, not validation of a solution people would integrate into their lives. The difference between mere feedback and validation lies in having a clearly defined and documented validation strategy that yields actionable insights and signals.

The Validation Journey

.Your validation strategy should include the following:

• Clearly defined goals and hypotheses: Articulate the value proposition and document assumptions about your target audience and market.

• Identified core assumptions: Determine which critical assumptions must be true for your product idea to evolve into a sustainable business.

• Diverse validation methods: Utilise various approaches including surveys, interviews, prototyping, and minimum viable products to gather comprehensive insights.

• Predetermined success criteria: Establish specific thresholds that indicate validation success and measure results against these standards.

• Iteration framework: Define how validation insights will be used to refine the product concept before proceeding to full development.

Recognising True Validation

How do you know when you've achieved validation? Look for these signals:

1. Achievement of predefined success criteria: You've reached or exceeded the metrics you established before beginning validation activities.

2. Confirmation of problem-solution fit: People are engaging with and using your product or service, even in its most rudimentary form.

3. Consistent patterns across methods: Results from different validation approaches confirm recurring insights, indicating convergence and sufficient understanding.

4. Reduced business risks: Your team has successfully mitigated technical, demand, user experience, adoption, and business model viability risks.
   
   

Strategic Validation: A Balanced Approach

I advocate for what I call "strategic validation” which is a more nuanced approach to validation:

• Understand the progression of creating a business from a product idea. What most founders will always start with is an idea, which they then need to move to a concept that can be visualised in some form, and documented. From there you move to building a business case through systematic validation.

• Validate assumptions, not ideas. List all the assumptions that need to be true in order for your product to achieve product-market fit. Break down concepts into their component assumptions and prioritis

  e testing the riskiest ones.

• Match validation depth to risk exposure. Not all features or decisions warrant the same validation investment, in terms of time and effort.

• Set validation time boxes. Establish hard limits on validation cycles to prevent analysis paralysis.

• Diversify validation methods. Different approaches reveal different insights and combine quantitative data, qualitative feedback, and behavioural observation.

• Build validation into execution. The best validation often happens through progressive deployment rather than pre-development testing.

Moving Forward with Confidence

True validation gives you the confidence to proceed with product development knowing you're building something people need and will use. It transforms uncertainty into calculated risk and replaces guesswork with evidence.

Ready to implement a proper validation strategy for your next product initiative?

Download my free Validation Workbook or book a free consultation call with me if you would like feedback or assistance on your validation strategy or approach..

 Hi, everyone. Today, I'd like to walk you through what I've learned about product discovery and validation during my 15 years of building software products. Whether you're a startup founder or an established business looking to innovate, this guide will help you avoid common pitfalls and build something people truly want.

Before we jump into the technical aspects, let's start with the most important lesson in product development. Understanding the problem before falling in love with the solution. Let me share a real example from my own experience. When I first started looking for accommodation while I was traveling, I always felt frustrated by expensive hotel rooms that made me feel like just another tourist.

That's exactly what Airbnb understood so well. They didn't just build another booking website. They solve the real human need for affordable homing places to stay. This deep understanding of what travelers actually want made their solution special. Problem-first thinking is essential for creating truly valuable products.

Now that we understand the importance of problem-first thinking, put on your detective hat. It's time to master the art of customer interviews. By engaging directly with customers, you gather valuable insights and build lasting relationships by showing them you're committed to solving real problems.

Here are some essential tools when it comes to customer interviews. Ask open-ended questions about daily challenges. Focus on listening rather than selling. Record compensations for deeper analysis with their permission, of course. Look for patterns in customer frustrations. The key here is to gather authentic insights through active listening, documentation, and pattern recognition rather than rushing into pitching solutions.

With your customer insights in hand, let's analyse the competitive landscape. Start by identifying direct and indirect competitors. Then, systematically evaluate their strengths and weaknesses in product features, pricing strategies and business models, marketing approaches and target audience, customer reviews and pain points.

I know it's counterintuitive, but having competitors is actually good news. It validates that there's a real market demand for what you're building. Your goal isn't to be completely different. It's to be meaningfully better by tracing gaps in competitor offerings and focusing on what matters most to your customers.

This leads us to our next important step. Building on our market analysis, let's craft your products. Why should I care statement? Remember this golden rule. People don't buy features, they buy benefits. Think about it. People don't buy a mattress because of memory form technology. They buy a good night's sleep.

To develop a compelling value proposition, try these proven techniques. Use the jobs-to-be-done framework. Identify what tasks customers are trying to accomplish. Create a value proposition canvas to map customers’ pains and gains to your product features. Test different value statements with real customers through A B testing.

Now that we've defined our unique value in the market, let's explore just how big that market opportunity is. Knowing your market size is essential. for making informed business decisions and attracting investors. It helps you set realistic goals and allocate resources effectively, and identify growth opportunities.

Let's quantify our opportunity using the market sizing funnel. At the top, we have TAM, which is Total Addressable Market. Everyone who could potentially use your product. SEM which is a Serviceable, Addressable Market. People you can realistically reach. SOM which is the serviceable, obtainable market. Your likely market share.

With our market size understood, now comes the exciting part. Putting your assumptions to the test. Create simple experiments to validate your biggest assumptions. Build a landing page to test interest. Create simple prototypes for LE feedback. Set clear success metrics before starting. Welcome all feedback, even negative responses.

They help us learn and improve. Fun fact, I'm actually using this exact technique right now with my 90 day program. Check out the link in the description to see how I'm validating my own value proposition in real time. Or better yet, join the program. Now that you've validated your core assumptions, it's essential to develop a solid technical strategy.

This phase can make or break your product. A well-planned technical foundation ensures smooth scaling, efficient development, and long-term sustainability. Number one, choose technology that matches your specific needs, not just strengths. Plan architecture with scalability in mind. Break development into manageable pieces of work, often referred to as sprints.

Implement testing strategies from day one. The key takeaway here is to remember to be thoughtful about your technical strategy or risk rebuilds later on. As we wrap up, remember that every successful product starts with these fundamental steps. Don't rush the process. Take time to understand your market, validate your assumptions, and plan your technical approach thoughtfully.

The key takeaway is to understand the problem deeply before building solutions. Listen to your customers. You hold the keys to success. Test, validate before heavy investment.

Tech Stack & Skills

A tech stack is the combination of programming languages, frameworks, databases and tools used to build and run your software. Think of it as your building's foundation and framework - just as a skyscraper needs the right structural elements to stand tall, your software needs the right technological components to function effectively and grow over time.

Your tech stack shapes both your product's foundation and the talent pool available to build and maintain it. When choosing technologies, evaluate their industry trajectory carefully. Declining technologies will shrink your talent pool and increase costs due to their specialised nature.

Beware of "shiny new syndrome": adopting trendy but unproven technologies, only to discover they don't deliver on their promises. Instead, focus on a balanced approach using reliable, scalable and well-supported technologies. This foundation is essential for long-term success.

Whilst it may be tempting to cut costs by hiring less experienced developers, this strategy often backfires. Less experienced teams typically underestimate development time, take longer to complete tasks and require more revisions. The initial savings usually evaporate when you factor in these delays and additional work. Remember: choosing a development team based solely on cost, at the expense of experience and skill, rarely pays off.

Ownership & Access

Imagine investing heavily in your product, only to lose access to your codebase or platform credentials because of a mismanaged handover. I have worked with clients who faced this exact problem and sought my help. It's more common than you might expect, especially amongst non-technical founders.

Think of access as keeping a spare key to your car. Whilst others may drive it, someone in your organisation must always have the master key. Ensure you have administrative access to all systems, repositories and credentials tied to your product. This simple step could save your business from major setbacks.

Budget and Timeline

Software development costs are primarily driven by the time and effort of your development team. The equation is straightforward: the more time it takes to develop your product, the more it will cost. To ensure your budget aligns with your vision, follow this strategic approach:

1. Define Your Product Vision: What problem does your software solve, and for whom?

2. Create a Roadmap: Collaborate with your team to outline your product's development stages.

3. Break Down Features: Divide features into smaller, manageable tasks to estimate effort accurately.

Final Thoughts

These considerations (tech stack, ownership, team experience and budget planning) are vital for successful software development. With the right strategy, you can avoid common pitfalls that derail projects and position your business for success.

Good Work Takes Time, But Business Can’t Always Wait

What made me a good software developer actually worked against me in business. When building software, I had a tendency to create the most robust systems that could withstand all sorts of scenarios. While this attention to detail is important in software development, it's not always beneficial in business. Customers simply want solutions that solve their problems. If you spend a month preparing a comprehensive proposal that covers every possible scenario, you might find that your competitor wins the deal with a simpler proposal that addresses the customer's core needs.

Broken Trust Isn’t a Bug You Can Patch

In software development, we expect things to change and often stress-test systems to their limits to find breaking points. However, this approach doesn't translate well to business. When a business fails to deliver promised value to customers, it erodes trust immediately. Unlike software development, you can’t deploy a fix to mend broken trust.

Build it and they won’t just come

In my early days, I thought an exceptional product or service would sell itself. If I offered the best, surely customers would come, right? Wrong.

Business isn’t just about what you build*.* It’s about how you connect with people, understand their needs, and build relationships. Customers choose to work with those they trust, and trust comes from authentic interactions, not just outstanding features or expertise.

Final thoughts

Building a successful software product means balancing technical skills with a solid business strategy. Even the best code is just code without a business strategy to sell it and communicate its value it won’t sell itself. Business success depends heavily on soft skills and building relationships, neglecting these can be disastrous. Only after learning these lessons did my business begin to gain traction. Whether you're an established business or a startup developing software, you must build your business model in parallel with your product to achieve success.

Access to information and large language models has made software creation more accessible than ever. Rather than diminishing software's value, these advancements have amplified it. This mirrors how broader access to education hasn't decreased the value of writing—instead, it has created more opportunities for creative and impactful expression. By removing technical barriers, anyone can now develop software that solves meaningful problems.

But the question remains: How do we build software that delivers true value?

What is Value?

To create valuable software, we must first define value. Simply put, value is the benefit a product provides to users relative to the cost or effort required to obtain it. A truly valuable product isn't just one that customers praise—it's one they're willing to pay for.

While value takes many forms—including the community-driven success of open-source projects—this discussion focuses on value measured by customers' willingness to pay, which validates your product's worth.

Understanding Subjective Value

Value is inherently subjective—what's essential to one user may be irrelevant to another. To gauge your product's real-world value, set a minimum viable price early, tied to your minimum viable product (MVP).

This pricing creates a natural filter, attracting only genuinely interested customers. Their willingness to pay becomes a clear measure of your product's perceived value.

Iterating on Both Product and Business Model

As you refine your product to meet customer needs, remember to iterate on your business model. These elements should evolve together. Ask yourself:

• How valuable is the current iteration of my product?

• What payment models will work best for my target customers?

By improving both the product and its monetisation strategy, you increase your chances of achieving product-market fit. This dual approach ensures your product not only solves problems but does so sustainably.

Value Through Efficiency & Effort Reduction

Think about value in terms of saved effort and increased efficiency: How much work, time, or resources does your software help customers conserve? For instance, an AI-powered solution offering 24/7 customer support delivers value by cutting both labor costs and wait times.

Quantify this value by comparing your solution's cost against traditional approaches. This comparison often reveals your product's worth through concrete savings and efficiency gains.

Final thoughts

When developing your MVP, treat customer willingness to pay as a core signal, not just another metric. By incorporating pricing feedback early and evolving your business model alongside your product, you ensure both align with what customers truly value.

When the vision is unclear, teams are forced to make assumptions. This leads to rework, wasted resources, and frustrated stakeholders. Often, it signals insufficient exploration of the core problem.

In today's edition, I'll take you through three essential steps to help you think more clearly about your product. These steps will guide you in crafting a focused vision, defining a coherent strategy, and executing effectively.

Step 1: Craft a Clear Product Vision

The starting point for any software product is answering the question: What is the product vision? Or as I like to call it, "the big idea."

While it's possible to build software without a vision, having one transforms your work from merely functional to purposeful. A clear vision serves as your guiding light, shaping decisions and priorities.

For example, if you're building an app to help students find accommodation, the product vision could be "Helping students find a home away from home."

Principles for an Effective Vision:

1. Think big—a bold vision attracts top talent.

2. Make it inspirational—it should motivate your team.

3. Keep it concise—clarity comes from simplicity.

Step 2: Define your product strategy

A product strategy bridges your vision and execution. It answers three critical questions:

Who is it for?

This describes your intended target market—their needs and how they'll benefit from your solution.

Example: Rather than saying, "Our app is for students," specify: "Our app helps international students find affordable, high-quality housing while navigating a new city."

What makes it different?

Highlight your product's unique value. Focus on features or benefits that set it apart and provide real, tangible value.

Example: "Unlike traditional rental platforms, we provide university-vetted housing options and a community-driven roommate matching system."

Why now?

Timing matters. Why is this product relevant today? Why can't people stick with existing solutions? These questions help define your opportunity.

Step 3: Make a Plan and Execute It

Execution transforms your vision into reality. It's where collaboration and strategic effort bring your product to life. A solid execution plan hinges on two key components: goals and projects.

Set Clear Goals

Use frameworks like SMART goals or OKRs to create quarterly objectives. These goals should:

• Guide your team's efforts. Clear goals provide direction and focus.

• Set tangible targets. Specific objectives foster accountability.

• Measure progress. Measurable goals enable evaluation and timely adjustments.

Plan Your Projects

Projects are the deliverables that propel you toward your goals. When structuring projects:

• Deliver value early. Don't wait for perfection—share your progress with users as soon as it provides benefit.

• Embrace iteration. Continuous delivery encourages user feedback and facilitates learning.

• Define success clearly. Project completion should include feedback, user insights, and measurable outcomes.

Remember: Success isn't just about shipping software—it's about delivering impact and creating genuine value for your customers.

Final thoughts

Building great products boils down to nailing these three things: vision, strategy, and execution.

• A clear vision inspires the team and provides direction.

• A solid strategy defines your product's positioning and unique value.

• A well-organised execution plan transforms ideas into tangible results.

Just remember: Start with clarity, keep everything in sync, and you'll be on the road to success.

Prioritisation not only highlights what’s essential but also helps eliminate the stress of “missing out” on less critical tasks. Without clear priorities, teams can face constant direction changes, leaving everyone unclear on what truly matters.

MoSCoW

One of my favourite frameworks is MoSCoW. This simple method categorises tasks into four priority levels:

Must have, Should have, Could have, and Won't have—which is also how it derives its name. What's great about it is that it gets you to categorise features according to necessity.

Must-haves

These are essential features for your product. Failure to have these  makes your product incomplete.

Should-haves

These are important features but they are not critical. They should be next in line if resources allow after must-haves have been completed.

Could-haves

These are features that are nice to have but don't have a high impact on the core functionality of the product if left out.

Won't-haves

These are items that have been deprioritised and may be revisited at a later time.

Impact vs Effort Matrix

Impact vs Effort is another excellent method that encourages you to think about features based on their value and complexity. It works by evaluating each task based on its potential value and the effort required to complete it —which can include resources, time, and complexity.

Value can be determined by how close a feature brings you to your goal. For example, if your goal is to increase monthly subscriptions, a feature with the highest likelihood of increasing subscriptions would be considered highly valuable.

Effort can be determined by estimations from the development team. Different teams use different approaches; Some teams use relative measures like t-shirt sizing or Fibonacci sequences for estimations, rather than exact time estimates (a topic I’ll dive into soon)

After determining value and effort, map features on a 2x2 grid to guide prioritisation:

High value, Low effort

These tasks are considered quick wins and should be prioritised immediately.

High value, High effort

Tasks in this category require careful planning. I recommend working on them early in the development sprint while the team is still energised.

Low value, Low effort

You can treat items in this category similar to could-haves in MoSCoW; they can be included if time allows.

Low value, High effort

You may want to avoid items in this category as the offer very little return on investment

Final thoughts

To effectively prioritise your product development efforts, consider utilising frameworks like MoSCoW or the Impact vs. Effort Matrix. These proven methods help align your team on what truly matters, enabling you to deliver high-impact features first.

I'm not suggesting that one needs to know everything before starting to build or that you can't run calculated experiments. What I mean is that without a proper plan—including systems and processes to move you forward—it's just trial and error. This approach will cost you not only money but also time.

Here are a few questions to consider before you start building:

1. Why is it important?

Ask yourself: Why does the world need what you're trying to build? If your answer isn't compelling enough, don't waste your time. There's no shortage of products the world doesn't need. Just check your phone for apps you've installed but never used. That's why it's crucial to ask yourself this question.

I apply this questioning not only to the product I want to build but also to its individual features.

Here's a framework I usually follow:

Who: Describes who the thing you're building is for

What: Describes what the thing is

Why: Describes why the thing you want to build is important

2. What will it take?

Once you're clear on the "why" of your value proposition, the next step is to understand what it will take to build it. In software development, this step is usually called refinement. This stage is where you dissect the requirements of the value proposition. You set and clarify an acceptance criteria, which defines how you will know when the thing you  set out to build is done. 

Once you're clear on the requirements, it becomes easier to determine what it will take. To do this well, you'll need input from experts such as developers and designers to give estimates of the required effort. Keep in mind that estimates are just that—estimates. Plan for worst-case scenarios.

Good estimations consider the following:

1. How much effort will it take to build the thing?

2. How much effort will it take to test the quality of the thing?

3. How much effort will it take to document how the thing works?

4. How much effort will it take to get the thing into production (in the hands of your customers)?

3. What will success look like?

It's crucial to clearly define what success will look like when your product  is complete and in the hands of its intended audience. Will it result in increased sales, higher user engagement, or more leads? Whatever the desired outcomes are, they must be well-defined, and steps should be taken to ensure they can be achieved.

 Getting your product into customers' hands is just the beginning of an opportunity to delight them repeatedly. Consider how much time they're spending with it. Do they use it once and never return, or are they recommending it to friends?

Final thoughts

These considerations can significantly improve your chances of success in building software products. One crucial point I've saved for last is the importance of systems and processes to facilitate your journey. To build effectively, you need clear systems and processes that everyone involved in bringing your vision to life can follow. 

You should be able to gauge progress toward your goals at any given time. The right systems and processes not only inform you about the required resources, but they also drive the quality of your software product.

PS

If you've made it this far, thank you for your attention.

I've been building software for over 15 years and would love to share my experience and expertise with more people like you.

If you have friends or colleagues who might benefit from posts like this, please encourage them to follow me on LinkedIn or subscribe to my newsletter.

This realisation hit me hard as I reflected on my experience trying to convince businesses to innovate.

Here's what I've learned:

Many organisations struggle with these key concepts:

1. Effectiveness which is doing the right things, and achieving desired outcomes. This is where strategy meets execution.
2. Efficiency which is doing things right, and optimising processes. This is where I spent most of my time.
3. Innovation which is about creating new solutions, challenging the norm. This is where I'd like to get them.

Organisations that excel at innovation:
- Use efficiency to free up resources for creative pursuits
- Streamline processes to enable rapid prototyping and iteration
- Use efficient systems to help scale innovations quickly

The lesson? To innovate successfully, companies must master efficiency without being constrained by it. They need to be effective in choosing the right problems to solve. Only then can true innovation flourish.

Transitioning from service to product is one of the best opportunities for businesses with a track record of service success. This transition propels your business forward and amplifies value for your customers.

Yet, many businesses remain unaware of the potential to transform their services into products, much less how to go about it.

If you are wondering why even border productising here are some key benefits

• Scalability: Imagine reaching more people without working around the clock. That’s what products can do!

• Predictability: Products can keep the cash coming in more predictable revenue streams than services that can go up and down.

• Efficiency: Once you’ve set up your product, it takes care of itself much more than any service.

• Market Reach: Digital products don’t have borders. Sell to anyone, anywhere!

• Competitive Advantage: Unique products can differentiate your business from competitors.

• Customer Value: Products can often provide more value to customers by solving their problems more effectively and efficiently than services.

If your service is already a hit, you’re halfway there. You’ve got customers who trust you and a service that’s proven its worth. Now, let’s figure out how to turn that into a product that adds even more value.

Here are some steps to follow in productising your service

1. Cultivate a Product-Minded Culture

Transitioning to a product-focused business requires a mindset shift. Success as a service provider doesn't guarantee product success. Inspire your team to embrace this new direction, fostering a culture that supports product innovation.

2. Commit Resources to Product Development

Unlike services, product development demands significant upfront investment. Define your business objectives and budget early, refining your investment strategy as your product vision sharpens through product discovery.

3. Define your product strategy

Your product strategy should articulate who your product serves, the challenges it addresses, and how it stands out, guiding your efforts toward fulfilling your vision.

3. Iterative discovery: Identify the right thing to build

You need to understand your customer’s needs to build the right thing. At wisemind, we call this phase of product development iterative discovery and it involves:

1. Identifying customer problems and desires

2. Brainstorming solutions

3. Validating these solutions through prototyping, testing, or launching a Minimum Viable Product (MVP)

5. Sell

The ultimate test to determine your product’s viability and how much customers value it is to offer it to them for a price. Make it easy for your customers to pay for the product.

Finally

Here are some questions to consider before you productise

1. Who are your ideal customers for the product?

2. How does your product stand out from the competition?

3. Is your pricing strategy aligned with your cost structure and market expectations?

4. How scalable is the product model?

If you're ready to transform your service into a product or develop a new digital product, I'm here to guide you. Reach out to me to explore how we can turn your great service into an even greater product

There’s a better way to build, one that puts the customer at the heart of what you build instead of the focus being on the competition, one that prioritises what your customers truly need instead of what you think they need. I am talking about iterative product discovery, the process of discovering the right product to build.

If you have an existing product and the ideas for new features just can’t stop coming, or you have a great idea, one that will create value for your business and customers, before you rush on and start building consider applying the following iterative discovery measures to ensure that you work on the right things.

Define the business value you want to achieve

Any product you build should be able to deliver some form of business value. More importantly, to enable that value to be delivered the product should be supported by a strong underlying business model.

Define your customer needs, problems, and desires.

Customers find value in solutions that either meet their needs, and desires or solve their pain points. However, depending on the severity, they are more likely to prefer solutions that solve their biggest pain points. It’s all a matter of prioritising to solve the biggest pain points to the least pain points 

Creating detailed user personas based on research is one of the best ways to help you empathize with your users and customers. Empathy helps us create features tailored to our customer's needs and behaviours.

Ideate on a  solution

This is a creative process that helps you ideate and conceptualise solutions to the different problems your customers face. All ideas are welcome at this stage, the idea is to keep an open mind and make room for different solutions to surface.

Select your ideas based on what is feasible technically, financially or operationally.

Prototype and test

Create prototypes that allow you to validate and test your assumptions with minimal resources quickly. It is important to have a criterion for what success looks like for a prototype. Once a prototype has successfully passed testing it can make it into development the out to the market.

Conclusion

Iterative discovery is about continually asking yourself the following questions at any point in your product cycle,

1. Is the product you are building delivering real, measurable business value?

2. Is your product meeting a need?

3. Are you continually ideating and improving upon your solution?