Product Discovery and Planning

Why Do We Build Software?

Imagine this situation: you’re standing in the kitchen, your hands covered in flour, frantically searching through a drawer for a yellowed piece of paper with your grandmother’s signature cake recipe. It’s not there. Again. A brilliant idea starts to form in your head: “What if I built an application – a digital cookbook where I could keep all my recipes at hand, and on top of that, by taking a photo of the ingredients in my fridge, AI would automatically generate new recipes using what I already have?”

Congratulations – you’ve just come up with a software idea.

Regardless of whether your goal is to build that cookbook, create a personal gym trainer, or develop a large-scale application for thousands of users, the beginning always looks the same. You’re full of enthusiasm and want to jump straight into writing code. Stop. The worst thing you can do at this point is dive into programming without proper preparation.

In this chapter, you’ll learn how to move step by step from a loose idea to a concrete action plan, while avoiding the most expensive mistakes in the IT world. Keep one principle in mind: in software development, ideas and requirements can change very quickly, and all initial assumptions can (and should) be challenged.

Problem Discovery: Define the Problem Before You Try to Solve It

Before you start thinking about solutions, you need to clearly understand what you’re dealing with. If you skip this step, you risk building a great solution to a problem that doesn’t actually exist.

This process is called Problem Discovery. It involves asking yourself a series of difficult questions before investing your time and money. Consider the following:

Why is solving this problem important at all?
What happens if we don’t solve it?
Can this problem be solved without building software?
What concrete value will this bring?

In the case of our cookbook, the problem is not “the lack of an app.” The real problem is chaos and a lack of experience in coming up with new meals. User pain points are the frustrations you encounter in everyday life. This could be losing loose recipe notes, struggling to quickly find something to cook, or the fact that no existing recipe uses only the ingredients you currently have in your fridge.

If you identify these real problems early, it becomes much easier to prioritize features and avoid building things no one will use.

Product Discovery: Separating Good Ideas from Bad Ones

Once you understand the problem you want to solve, you move into the next phase: Product Discovery. This is a research process where you validate whether your solution idea (e.g., a digital cookbook) actually makes sense before investing time and money into building it.

The goal of Product Discovery is to quickly filter out bad ideas and keep only those that are:

Valuable to users (they actually want to use them).
Intuitive to use.
Technically feasible.

We often think we know what people want. That’s a trap! Building an application based purely on assumptions or investor expectations often leads to features that nobody needs. According to various studies, around 40% of features in finished products are rarely or never used. That’s why it’s crucial to talk to potential users and validate assumptions using simple sketches, surveys, or interviews before writing any real code.

Focus on What Matters: MVP

Once you know your application solves a real problem, it’s time to start building – but not a “grand palace” right away. Instead, you build an MVP – a Minimum Viable Product, meaning a version of your product that includes only the core functionality.

Many people mistakenly believe that an MVP is something poorly made or full of bugs. That’s not the case. An MVP is the simplest version of your application that still solves the user’s core problem.

Why is MVP such a powerful approach?

You save time and money: building less means reaching the market faster
You gather real feedback: instead of guessing, you observe how real users behave
You reduce risk: if the idea fails, you lose a month – not two years

Let’s apply this to our cookbook. Your long-term vision might include integrations with online shopping lists, automated grocery ordering, social features for sharing and liking recipes, and AI generating meals based on fridge photos. Sounds great right? But that’s not an MVP. Your MVP should include only what’s absolutely necessary to solve the main user problem. For example: converting a photo into a recipe. That’s it. You release it, observe whether people actually use it, and only then decide whether to expand the product. This is known as the Build–Measure–Learn loop.

Software Development Lifecycle: An Engineering Perspective

To move efficiently from idea to MVP, the IT industry developed the concept of the Software Development Life Cycle (SDLC). It’s essentially a roadmap that breaks the process into structured, repeatable stages.

Typically, SDLC consists of seven steps:

Planning: defining the project’s goals and scope
Analysis: gathering detailed requirements
Design: planning system architecture and UI/UX
Implementation: developers build the application
Testing: identifying bugs and verifying functionality
Deployment: releasing the application to users
Maintenance: fixing issues and releasing updates

How do you organize this process? There are two main approaches.

The first is Waterfall – a traditional model where everything is planned upfront and executed step by step. The downside is limited flexibility. If halfway through the project you decide to pivot – for example, from a consumer cookbook app to a catering management system with inventory and supplier integrations – making changes can be difficult. That said, Waterfall works well for large systems with clearly defined requirements and a low likelihood of change – for example, military systems.

The second approach is Agile. Here, work is divided into short cycles (called sprints), after which you deliver a working piece of the application and gather feedback from users. This makes it ideal for MVP development and products shaped by user feedback. Despite its popularity, Agile is often misunderstood. Many people think it’s mainly about meetings – daily standups, sprint demos, sprint planning – but they miss the core idea. If you remember one thing about Agile, it should be this: its primary goal is to increase user value with every sprint. If, at the end of a sprint, the product is not easier or more useful for the end user, then Agile is being applied incorrectly.

In practice, especially in larger projects, pure Waterfall or pure Agile is rare. Most teams use a hybrid approach – starting with Waterfall-like planning for budgeting and high-level structure, then switching to Agile during implementation to stay flexible and responsive to feedback.

The Golden Rule: Clean Up Before You Automate

Finally, we need to address a fundamental principle of optimization.Whether you’re building an application, running a factory, managing a production line, or optimizing a business process – this rule always applies. Elon Musk, while managing large-scale manufacturing operations, formulated a simple algorithm that works remarkably well in software development:

Question every requirement: Never accept requirements or “best practices” as unquestionable truths. Always ask why and challenge assumptions – even if they come from senior management. Each task must have exactly one responsible person – someone you can discuss the underlying assumptions with and clearly understand why things are designed the way they are.
Remove anything unnecessary: Simplify as much as possible by removing anything that is not crucial. You can always add things back later. If you don’t end up restoring at least 10% of what you removed, you probably didn’t remove enough.
Simplify and optimize: Only after removing unnecessary elements. One of the biggest mistakes in IT is optimizing features that shouldn’t exist in the first place.
Accelerate the process: Every process can be made faster – but only after going through the previous steps. Elon Musk has noted that at Tesla, he ended up speeding up processes that should have been eliminated altogether.
Automate last: Automating a broken process only gives you faster chaos. Introduce advanced solutions only when the process is already clean and validated.

What does it mean for you? Before writing complex automation code, ask yourself whether the process is even necessary. Challenge every assumption and every feature. Remove anything that isn’t critical. A common mistake among beginners is optimizing and automating processes that should never have existed.

If adding a recipe in your cookbook app is too complicated, don’t write an algorithm to guess what the user meant. Simplify the form first.Don’t automate chaos. Think first, clean up, then code.

Summary

By now, you should understand that building great software is not just about typing fast or generating code with AI. It’s a process. You start by understanding the real problem (Problem Discovery), validate your ideas (Product Discovery), and then build the simplest possible version that delivers value (MVP). You do all of this within an iterative development process, always remembering to simplify before automating. Then you gather feedback from users and improve.

Once you’re confident about what you’re building and why, another fundamental question arises: How do you structure it technically so it doesn’t collapse when a thousand users start using it at the same time? That’s what we’ll cover in the next chapter – where we’ll dive deeper and explore software architecture in detail.

Materials

Self-study materials that are related to this topic: