You can’t build blind
Before committing resources to product development, organizations must establish a solid strategic foundation to ensure a product is desirable, viable, and executable. Rather than mistaking feature requests for strategic rationale, teams must define a clear vision and value proposition while accurately diagnosing underlying customer problems. A thorough evaluation requires validating market demand, aligning ambitions with operational capabilities, verifying financial feasibility, and mitigating multidimensional risks. This rationale is formalized across three core artifacts: the Vision Brief, which clarifies strategic intent and customer value; the Business Case, which evaluates investment merit; and the Feasibility Report, which assesses technical, legal, and operational constraints. Ultimately, this preparation enables informed decisions to proceed, iterate, test, or stop before incurring delivery costs.
FIG 1.0 - Fishing for new ideas.
The first step to starting a new project is trying to get a novel idea but finding a truly novel idea is often less about waiting for a sudden flash of inspiration and more about following a structured exploration process.
Related Insights
Governance Is How Work Becomes Decidable
Productivity Is Not What We Think It Is
When Enough Is Not Enough: The Work-Enablement Problem
MXI.STUDIO EDITORIAL
Productivity | Work | Metrics | Operations
The MXI.Studio Editorial is a collection of articles, ideas, and reflections written by the people behind MXI.Studio. We explore emerging technologies, innovation, industry trends, and the current challenges of an ever-evolving world.
You can’t build blind.
"Why the first step to starting something isn’t planning it but establishing what “it” is."
T here is a particular excitement that comes with an idea. You notice something frustrating, imagine a better way, and almost immediately start thinking about how to make it. The features, the tools, the name. Perhaps you have already pictured the finished result before asking whether anyone needs it.
That enthusiasm is useful. You will probably need it. But it can also carry you past the questions that decide whether the project makes sense in the first place.
You can build something that works exactly as intended and still discover that people have no reason to use it. You can solve a problem that an existing product already solves well enough. You can finish a device and find that getting it ready for sale costs more than developing it did. Or you can create something useful that you simply cannot afford to maintain.
Being able to build something does not, by itself, give you a reason to build it. Unless, of course, proving that you can is the point. A learning project is a perfectly good project, provided you are honest about what you want from it.
This first stage is about establishing that purpose and finding out whether your idea has a realistic path forward. It applies whether you are working alone, starting a business, organizing a community service, or developing something with a team. The scale changes. The need to understand what you are getting into remains.
Much of this work looks like
research, conversations, rough calculations, and thinking. It can feel
slow because there is little to show yet. But an afternoon spent
discovering that a critical assumption is wrong can save months of
building around it.
The aim is to give your enthusiasm a direction you have good reason to
follow.
Having an idea is only the starting point
Ideas can begin almost anywhere: a recurring inconvenience, an unfamiliar technology, a conversation, something you wish existed. Sometimes you encounter an existing product and think, “Surely this could be done better.”
All of these are reasonable places to start. None tells you, on its own, that you have found a worthwhile project. Just because you have never seen something does not mean it does not exist. You may be using different words to describe it. It may serve another industry, be sold in another country, or appear as one small feature inside a much larger product. Your first job is to look beyond the version of the idea already in your head.
Imagine finding a frustrating limitation in a large software package. You could build a competing product that fixes it. But how much of the surrounding software would you need to recreate before anyone could switch? Would people give up familiar workflows, integrations, and years of stored information for your improvement? And what happens if the existing provider fixes the same limitation while you are still rebuilding everything else?
The problem may be real, but fixing it usually presents a tough trade-off: either you build a minor workaround, or you rebuild an entire complex product just to enter the market. Instead of taking on that whole burden at once, a better approach is to slow down, reframe the problem, and start with a much smaller, highly focused solution you can iterate from.
Richard Rumelt’s Good Strategy/Bad Strategy helps explain why this distinction matters. He describes strategy as a diagnosis of the challenge, a guiding policy for addressing it, and coherent actions that follow from that policy. Applied here, the lesson is straightforward: understand what makes the situation difficult before deciding what to build. If the obstacle is that people cannot afford existing tools, adding more features may do very little. Your approach needs to follow from the problem you actually find.
Find out whether it matters to anyone
Once an idea seems worth investing time in, look closely at what the situation looks like from another angle. “People need an application” tells you what you are imagining. It says very little about what those people are experiencing. “People give up trying to book a repair because they cannot confirm an appointment without calling during working hours” gives you something to investigate.
Who runs into this difficulty? How often? What happens when they do? Do they call another shop, put off the repair, or find a workaround? Is the inconvenience serious enough to change their behavior? It is not necessary to have a perfect problem statement before talking to people. What is required is curiosity enough to be altered by their responses.
Ask about the last time the situation happened. What did they do? What did it cost them in time, money, or effort? If they tried another solution, why did they keep it or abandon it? These questions usually give you more to work with than asking whether they like your idea. It is easy to approve of an imagined product when approval requires nothing from you.
Steve Blank’s customer development approach makes this investigation part of the work from the beginning. The initial idea contains hypotheses about customers, their needs, and how the project might function. Those hypotheses need to meet people’s actual circumstances. A conversation is useful when it helps test them, including when the answer is inconvenient. For your project, that might mean learning that appointment availability is less of a problem than uncertainty about the repair price.
Eric Ries’s The Lean Startup carries this into experimentation through the Build–Measure–Learn cycle. You make a limited test, observe what happens, and use the result to decide what to do next. In the booking example, you could trial a simple request form with a participating shop and handle confirmations manually. That might reveal whether people complete requests and whether the shop can respond reliably before you invest in an automated system.
Make sure to be clear on what such tests prove. The submission of a form means that they showed interest. The completion of the booking indicates another thing. And the repeated use means something completely different. All these do not guarantee your ability to attract paying customers for your service.
Sometimes, a project starts with an experience that has never been seen before, instead of the usual problem. It could be a game, artwork, or experimental tool, which needs a sample first for someone to give their opinion. In this case, a test is a part of your research. You learn what attracts people before making the full-scale product.
SIDE NOTE :
What are people actually trying to accomplish? The Jobs to Be Done perspective, associated with Clayton Christensen and his collaborators, examines the progress people seek in particular circumstances. Someone booking a repair may want the reassurance of knowing their car will be ready before they need it for work. Seeing that broader purpose can change your idea of what a useful solution should do.
Look at the world your idea will enter
Your project will arrive in a world where people already spend their time, attention, and money. Even when nothing looks exactly like your idea, something usually occupies the space you hope to take. An appointment service competes with other appointment services, but also with phone calls, messages, calendars, and familiar habits. A community workshop competes for people’s Saturday afternoon. A personal automation project has to improve on a task you may already complete in a few minutes.
Investigating this landscape helps you determine whether there is genuine room for your project and what it will take to succeed there. To map out the world your idea will enter, start by examining these key aspects:
Tab 1 — A structured breakdown of key competitive and market dynamics to investigate when evaluating the viability of a new project idea.
Michael Porter’s competitive strategy work is useful here because it looks beyond a list of rivals. His Five Forces framework considers existing competition, new entrants, substitutes, and the bargaining power of buyers and suppliers. You do not have to conduct a formal industry analysis to benefit from that wider view. If one supplier controls an essential component, or a platform can change the price of access your service depends on, those conditions belong in your thinking from the start.
Trends must be treated with the same level of diligence. An increase in interest may indicate an opportunity, but interest is not demand. Investigate what is going on behind the hype. Has a new technology become cheaper? Is there a new behavior that people are adopting? Is an existing choice now more difficult? There is something solid to look into here.
Finding competitors shouldn't mean
ending your project; it often proves that a real market already exists.
Finding none, however, should raise further questions: Have you
uncovered a
genuine opportunity, searched using the wrong terms, or stumbled onto a
problem that is simply too difficult to build a business around?
What matters is whether you can identify a credible place for your idea
amongst the available choices.
What about in the long run?
"An opportunity can be attractive without being a sensible commitment for you right now. "
Take an honest look at what the project requires and what you have available. That includes skills, money, time, equipment, access to information, and people you can realistically rely on. If the idea depends on a component you cannot obtain or data you have no permission to use, that is a condition to resolve before building around it.
There is always more to learn, but that is not stopping us. Most worthwhile projects ask you to do something you have not done before. The distinction is whether you have a plausible way to close the gap. Learning a new tool over several weekends is different from relying on a scientific breakthrough or an unavailable specialist.
Test the complicated bits early on. If your project depends on reading a sensor accurately in a difficult environment, test that. If it needs another system to provide reliable information, check the access and the quality of the information. A narrow experiment can reveal far more than a polished demonstration built around assumptions.
Then think beyond the first working version. Try covering all the expected scenario. Who handles the broken device, the failed update, the confused user, or the supplier that stops making a part? If the answer is you, include that work in the commitment. Being able to make one example function does not establish that you can manufacture, deliver, or support it repeatedly.
This is also where existing solutions deserve another look. You might buy the equipment, adapt an available tool, use a supported service, or work with someone who already has the missing capability. Originality does not require you to recreate every layer underneath the useful part of your idea.
If the full project exceeds your resources, ask whether a smaller version still delivers something worthwhile. If it does not, postponing or leaving the idea alone can be a sound decision. You have learned something before accepting obligations you cannot meet.
Know who you are targeting
"As you learn more about the problem and your own limits, the audience should become clearer."
“Anyone could use it” may be true. It gives you very little help deciding what to make first. Different people can face a similar problem while needing very different solutions. A booking system for a large repair chain might need multiple locations, complex permissions, and connections to other software. An independent mechanic might mostly need an easy way to confirm a slot without interrupting a job. A tool designed around that second situation could be useful without outperforming the larger system on every feature.
This is why adapting an existing idea for a different audience can be a meaningful project. The opportunity may lie in simpler setup, better accessibility, a different language, local support, a lower cost, or a workflow that established products handle badly. The difference needs to matter to the people choosing it.
Alexander Osterwalder and his co-authors develop this connection in Value Proposition Design. Their approach links what customers are trying to accomplish, the difficulties they encounter, and the gains they seek with what an offering actually provides. Applied to the mechanic, “online scheduling” describes a capability. “Let customers request a repair slot after hours without adding more calls to your working day” expresses a benefit you can investigate.
FIG. 2 — Finding our own project.
a product does not need to match the size or complexity of massive enterprise solutions to deliver meaningful value. Focusing on a specific, well-defined audience allows a smaller project to streamline workflows, eliminate unnecessary friction, and succeed by excelling at a single, targeted need rather than serving the entire market.
Remember that the user, the buyer, and the person doing the extra work may be different people. Customers might enjoy the convenience while the mechanic pays for the service and manages the schedule. The idea has to make sense across those relationships.
If you do not yet know your audience, choose a plausible first group and treat that choice as provisional. A broad tool may eventually find several uses. Testing one real use gives you a place to begin learning without pretending the entire market is already understood.
For a personal project, that first audience may simply be you. For a community project, it may be a small group of participants. The question remains useful: whose situation are you trying to improve, and what would make the improvement worthwhile to them?
Work out what the effort should bring back
A project consumes something: money, time, space, attention, or opportunities you could have pursued instead. Before committing more, decide what you expect in return. For a commercial product, that includes a credible prospect of profit. For a personal tool, it might be time saved or a skill learned. For a community service, it could be reliable access to something people otherwise lack. Different purposes need different measures, but each deserves an honest account of the effort involved.
Start with the whole commitment. Beyond development, you may need equipment, testing, hosting, materials, packaging, delivery, support, repairs, marketing, and eventual replacement. Include your own time, even if you are not paying yourself yet. It still limits what you can take on.
Then make a rough calculation grounded in the people you can realistically reach. A large market does not tell you how many customers will find you, trust you, and choose to pay. Think about how those first customers would arrive and what it would cost to serve them.
SIDE NOTE :
The financial shorthand CAPEX generally refers to spending treated as investment in long-lived assets; OPEX refers to operating expenses. The precise accounting treatment depends on the circumstances. ROI, or return on investment, compares the return with the investment under a stated method. Payback concerns how long it takes to recover the initial outlay. For an early decision, make the cash needs, continuing costs, and assumptions visible before worrying about the terminology.
Rita Gunther McGrath and Ian MacMillan’s Discovery-Driven Planning provides a useful way to work with these unknowns. Define what success would require, compare it with outside evidence, think through the necessary operations, record the assumptions, and revisit them at checkpoints. In our example, you might test the achievable selling price and obtain realistic production quotes before paying for a production run. Each step should help establish whether the next commitment makes sense.
Try a less favorable version of your calculation as well. What if sales take twice as long, costs rise, or support requires more time? A project that works only under ideal conditions needs more consideration.
For a project whose return is time saved, do the equivalent calculation. If an automation takes forty hours to build and saves ten minutes a week, recovering the build time alone would take roughly 240 weeks, before maintenance. It could still be an excellent learning project. But that is a different reason to undertake it, and knowing the difference helps you choose honestly.
Check what you are allowed to deliver
"Even a useful, affordable, technically achievable idea can run into requirements that change the entire project."
Electronics makes this perfectly clear. Getting a prototype to work on your desk is one milestone. Making a product you can legally offer for sale is another. Depending on the device and where you intend to sell it, testing, certification, labeling, and other compliance requirements may affect the design, budget, and schedule.
For example, Canadian guidance for radio equipment explains that incorporating a certified radio module does not remove all obligations for the final product. The host and module must meet applicable requirements, including relevant radio-frequency exposure requirements. An existing module can be a useful route, but you need to understand the conditions attached to using it.
For someone with a small budget, these considerations can change the sensible starting point. Look into whether an existing finished product, an appropriate module, or a partnership would let you deliver the useful part of the idea with a manageable compliance burden. Find out what remains your responsibility before treating any component as a shortcut.
The same habit applies elsewhere. A service may depend on permission to use information, software, or creative work. A physical activity may need particular approvals. The relevant questions depend on what you are doing and where, so investigate the requirements for your actual project and seek qualified advice where an unresolved issue could determine whether you can proceed.
You do not need every final approval before exploring an idea. You do need to identify the obligations that could make your intended version impractical. Discovering them early gives you room to change the design or scope while that change is still relatively inexpensive.
Defining Your Direction
By this point, the initial idea should be significantly more defined.
You should have a clearer understanding of the people involved, the
alternatives already available, what you can realistically deliver, and
the true cost of the effort.
The task now is to state the project in terms of what has been
discussed:
-
Impact & Scope: What becomes possible because this project exists, and whom do you serve first?
-
Value & Trade-offs: What specific benefit are you proposing, why would anyone switch, and what can you actually sustain?
-
Core Risk: Which unresolved assumption, if proven false, would change your decision to move forward?
Consider the repair example. The overarching vision might be making essential local repairs fit around working lives. However, the actual project can be far narrower. It could jut be helping independent mechanics manage scheduling and confirmations. You do not need to own every piece of a problem to deliver something real.
A value proposition simply
crystallizes that focus. It serves as a working hypothesis for why the
effort deserves attention, evolving as better evidence comes in.
To maintain clarity, document the process:
-
Distinguish facts from assumptions.
-
Define success in advance. Use specific metrics such as completion of appointment, repeated use, decreased administrative costs, or sustainable income instead of completion itself. Completion of your build is proof that you have done something, but it is not proof that it was worth doing.
Research is not an unending process; its aim is to make you take a stand: go ahead, repeat a focused experiment, redefine the target market, narrow down, find a partner, or give up. It depends on the risk involved in how much proof you need. A minimal and reversible experiment does not need as much proof as a big investment. Try to debunk those assumptions that can stop your entire project.
Approaching the start of a project with an engineer’s rigor means evaluating the environment, validating critical assumptions, and allowing reality to shape the design. It will not eliminate surprises, but it establishes a clear purpose, a grounded commitment, and a objective benchmark for when course corrections are needed. Where the initial idea provides a reason to start, this groundwork establishes a baseline worth building upon; marking the beginning of the Execution axis from the Power series.
text_snippet REFERENCES
1. Enterprise Project-to-Product Process Framework — Chapter 1, “Strategic Foundation”
Primary process framework named for this article; contents represented through the supplied outline.
2. Rumelt, R. P. (2011) — Good Strategy/Bad Strategy: The Difference and Why It Matters. Crown Business.
Find the book on Google Books3. Porter, M. E. (1980) — Competitive Strategy: Techniques for Analyzing Industries and Competitors. Free Press.
Find the book on Google Books4. Porter, M. E. (1996) — “What Is Strategy?” Harvard Business Review, 74(6), 61–78.
https://hbr.org/1996/11/what-is-strategy5. Osterwalder, A. & Pigneur, Y. (2010) — Business Model Generation. Wiley.
Find the book on Google Books6. Osterwalder, A., Pigneur, Y., Bernarda, G. & Smith, A. (2014) — Value Proposition Design. Wiley.
Find the book on Google Books7. Blank, S. G. (2005) — The Four Steps to the Epiphany. Cafepress.
Find the book on Google Books8. Ries, E. (2011) — The Lean Startup. Crown Business.
Find the book on Google Books9. Christensen, C. M., Hall, T., Dillon, K. & Duncan, D. S. (2016) — “Know Your Customers' Jobs to Be Done.” Harvard Business Review, 94(9), 54–62.
https://hbr.org/2016/09/know-your-customers-jobs-to-be-done10. McGrath, R. G. & MacMillan, I. C. (1995) — “Discovery-Driven Planning.” Harvard Business Review, 73(4), 44–54.
https://hbr.org/1995/07/discovery-driven-planning11. International Organization for Standardization (2018) — ISO 31000:2018 Risk Management: Guidelines.
https://www.iso.org/standard/65694.html12. Brealey, R. A., Myers, S. C. & Allen, F. — Principles of Corporate Finance. McGraw-Hill.
Standard treatment of investment appraisal and capital budgeting.
Find the book on Google Books13. Innovation, Science and Economic Development Canada — “Common Questions and Answers.”
Includes guidance on integrating certified radio modules into host devices. Consult the applicable current standards for a specific product and market.
https://ised-isde.canada.ca/site/certification-engineering-bureau/en/common-questions-and-answers