The Phase That Determines Whether Your Project Succeeds or Fails Before You Write a Line of Code
The Phase That Determines Whether Your Project Succeeds or Fails Before You Write a Line of Code
Series: The Modern SDLC · Post 1 of 17 ← Post 0: The Modern SDLC — A Field Guide · Post 2: Architecture Decisions →
Here's a failure pattern that plays out constantly in engineering teams: six months of work, a technically sound product, a launch — and then silence. Low adoption. Stakeholders quietly disappointed. A post-mortem that dances around the real answer, which is that nobody validated whether the problem was real, who it actually affected, or whether the solution addressed the thing people actually cared about.
The project didn't fail in development. It failed in the weeks before development started, when the team skipped the work that would have told them whether they were building the right thing.
Conception is the most leveraged phase in the entire software development lifecycle. The decisions made here — or avoided here — shape everything that follows. A well-run conception phase takes two to four weeks and can save months. A skipped conception phase looks like it saves two weeks and costs far more.
The one thing to remember
Understand the problem completely before proposing any solution.
Every hour spent on this buys you ten hours you won't spend rebuilding something that turns out to solve the wrong problem.
What actually happens in conception
Conception isn't a single meeting or a requirements-gathering session. It's a sequence of activities, each one building on the last, that produce a shared, grounded understanding of what you're going to build and why.
Done right, it ends with a document — the project brief — that every stakeholder has read, agreed to, and can independently summarise. That document becomes the ground truth the team refers back to for the next six months.
Done wrong, it ends with a kickoff meeting where everyone nods, leaves with different mental models of what's being built, and resolves the conflict in production.
Here's the sequence that works.
Step 1: Frame the problem before anyone proposes a solution
The first instinct when starting a project is to jump to solutions. "We should build a dashboard." "We need to integrate the APIs." "Let's add a notification system." These conversations feel productive because they're concrete. They're not.
Before any solution discussion, you need a clear, written problem statement. One paragraph that answers four questions:
Who has the problem?
What are they trying to do that they can't do well?
What is the current situation that makes this painful?
What does it cost — in time, money, or risk — to leave it unsolved?
The discipline is keeping solutions out of it. A problem statement that mentions a dashboard is a solution statement in disguise. If you can't write the problem without mentioning the solution, you don't understand the problem well enough yet.
A useful test: could two different engineers read your problem statement and propose completely different solutions? If yes, you have a problem statement. If no, you have a solution brief with the solution disguised as a problem.
Step 2: Map your stakeholders before the first meeting
Every project has three types of stakeholders, and most teams only think about one of them.
Beneficiaries are the people who gain from the project — users, customers, internal teams whose work changes. Their needs define what you build. Their adoption determines whether it succeeds.
Decision makers are the people who authorise, fund, and approve. Their alignment is what lets you proceed. Their misalignment is what stops projects mid-flight.
Gatekeepers are the people who can block you — security, legal, compliance, platform teams, procurement. They don't benefit directly from the project, but they must approve it. This is the category most teams discover too late, in the worst possible way: "you can't launch without our sign-off" at the end of month four.
The most important question to ask every stakeholder you meet is "who else should I talk to?" Follow that chain until names start repeating. The stakeholders you don't find in the first round are usually the ones who cause the most expensive surprises.
The power/interest matrix is the practical tool for deciding how to engage each person. High power, high interest stakeholders need to be managed closely — involved in decisions, updated frequently, explicitly aligned. High power, low interest stakeholders (the CISO, the CFO) need to be kept satisfied — brief them at milestones, respect their time, never surprise them. Low power, high interest stakeholders (often the actual users) are your best source of honest feedback and your potential champions — keep them informed and create channels for their input.
Step 3: Do user research before writing a single requirement
This is the step that produces the most resistance and delivers the most value.
The argument against it is always the same: "we know our users," or "we don't have time," or "we'll learn from the product once it's live." The counter-argument is simple: learning from users before you build costs a few weeks. Learning from a launched product that nobody uses costs months.
The most valuable research method at this stage is depth interviews — one-on-one conversations with five to eight people who currently experience the problem. Not surveys, not focus groups, not asking colleagues what they think users want. Actual conversations with actual users.
The question that unlocks the most insight is not "what would you want a tool to do?" It's "walk me through the last time you dealt with this problem." Past behaviour is honest. Hypothetical preferences are fiction.
What you're specifically looking for is workarounds — the spreadsheet alongside the official system, the Slack message to a colleague before submitting a form, the Post-it note on the monitor. Every workaround is a product gap that someone has filled with duct tape. These are your richest insights, because they reveal what people actually need rather than what they say they want.
Five to eight interviews is enough to identify the major patterns. You'll know you have enough when interviews stop producing new insights and the same themes keep repeating.
Step 4: Fill out an opportunity canvas
An opportunity canvas is a one-page structured document that forces the team to articulate the full picture before committing to anything. It takes two to three hours to complete collaboratively and surfaces more misalignment than any amount of pre-work.
The nine sections, in order:
Problem / opportunity — what problem are we solving and for whom
Solutions today — how people solve this now, including workarounds
Users and customers — who experiences the problem, who decides
User outcomes — what changes in users' lives if this is solved
Business outcomes — why the organisation should invest in this
Constraints and risks — what makes this hard and what could go wrong
Assumptions to test — what we believe that we haven't proved
Solution ideas — possible approaches, kept deliberately loose
How we measure — how we'll know if it worked
The order matters. Problem first. Solutions eighth. Teams that fill in section 8 first and work backwards are writing a rationalisation document, not an opportunity analysis. If you catch your team doing this, start over.
The section that reveals the most is section 7. Making your assumptions explicit — and then asking "which one of these, if wrong, would kill this project?" — tells you what to test before committing to a full build. The assumption that would kill the project is the first thing you test. Before any design. Before any engineering.
Step 5: Assess feasibility honestly
Feasibility assessment isn't about whether you should build something — that's the opportunity canvas's job. It's about whether you can, and at what cost, and under what constraints.
There are four dimensions, and all four have to pass.
Technical feasibility: Can you build it with the technology and team you have? Does the required data exist and is it accessible? Have you verified that the third-party APIs you're depending on actually work the way their documentation suggests? (They often don't — a technical spike to verify before you design around them is time well spent.)
Business feasibility: Does the value created justify the cost of creation? Is there an approved budget? Are the right team members actually available, not just theoretically available? Does this project advance an active strategic objective, or is it good work that's lower priority than other good work?
Legal and compliance feasibility: Does the project process personal data? If so, what's the legal basis, and does it require a privacy impact assessment? Are there industry regulations that impose specific requirements? Have you read the terms of service for the third-party APIs you're planning to use? This is the dimension most commonly skipped — and the most expensive to discover late, because compliance issues found after design can require architectural changes.
Operational feasibility: Will users actually change their behaviour to adopt this? Who will support it after launch — and does that capacity exist? Is the platform required to run it ready, or is there an infrastructure project that needs to happen first?
One outcome that doesn't get enough credit is "we need more information before deciding." Not a yes, not a no — a specific list of questions with named owners and deadlines. Proceeding without the information is how projects discover fatal flaws in month four.
Step 6: Define success before you start building
Success metrics defined before building get chosen to measure whether the problem was solved. Success metrics defined after launching get chosen to make the project look good. The difference in what you learn is significant.
Every project needs at minimum:
A primary success metric — the one number that best captures whether you solved the problem. One metric. Not five.
Secondary metrics — supporting evidence that the primary metric moved for the right reasons.
Guardrail metrics — things that must not get worse. Optimising hard for the primary metric at the cost of something else is a failure that looks like success.
A baseline — measured before you start building. A baseline measured after launch is contaminated; you can't separate pre-existing trends from your project's impact.
The practical question to ask before finalising any metric: "if this metric improves but nothing changes for users, what does that mean?" If the answer is "nothing," it's a vanity metric. Replace it with something that connects to actual user outcomes.
Step 7: Align stakeholders — and get written confirmation
This is the step most teams treat as a single kickoff meeting. It isn't.
True alignment means every key stakeholder can independently answer: what problem are we solving, what does success look like, what are we explicitly not building, and who makes the final call when there's a disagreement.
The process that actually works: individual conversations before any group session, to understand each stakeholder's perspective and surface concerns privately before they become public conflicts. Then a group alignment session structured around decisions, not presentations. Then a written project brief circulated to all stakeholders with one ask: "please reply to confirm this reflects what we agreed."
That last step feels bureaucratic until six months later when a stakeholder says "that's not what I agreed to." The email thread is the record. More importantly, the act of re-reading and confirming catches cases where someone's memory of the meeting differs from what was documented.
Run these five questions with each key stakeholder after your alignment session — individually, not in the group:
What problem are we solving, and for whom?
What will we definitely NOT build in this phase?
How will we know in 90 days whether this succeeded?
If timeline and scope are in conflict, which gives?
Who makes the final call if the team disagrees on direction?
If their answers diverge, you don't have alignment yet. Better to know now than in month three.
What goes wrong when you skip this
These failure modes are consistent across teams and industries. Recognising them is the value of having seen them before.
The solution trap. The team has a solution in mind before the problem is understood. Conception is run to justify the solution rather than discover the problem. The product solves the hypothesised problem — which turns out not to be the real one.
The missing gatekeeper. A security review, a compliance requirement, a platform dependency — discovered in week ten rather than week one. The architectural changes required add months to a project that was nearly done.
The assumed scope. Stakeholders leave the kickoff with different mental models of what's included. One assumes mobile support is coming in V1. One assumes it's explicitly out. The conflict surfaces when the design is already done.
The undefined success. Nobody agrees on what success looks like before building. After launch, every stakeholder evaluates the outcome differently. The project is simultaneously a success and a failure, depending on who you ask.
The skipped research. The team builds for their internal model of the user rather than the actual user. The product is technically sound and solves the wrong problem.
The output: a project brief
Every good conception phase ends with one document: a project brief. Not a 40-page requirements specification. Not a slide deck. A 2–4 page document that every key stakeholder has read and explicitly agreed to.
It contains: the problem statement, goals and success metrics, explicit non-goals, a description of the users, the constraints the project operates within, the key assumptions and risks, who makes what decisions, and the open questions with owners and deadlines.
The non-goals section is often the most valuable part. Scope that is assumed but not stated becomes a source of conflict mid-project. Non-goals that are named — "out of scope for V1: mobile app, real-time data, automated notifications" — can be pointed to directly when scope creep arrives, and it always arrives.
The brief is a living document. When scope changes, when new constraints emerge, when a decision is revisited — update it and re-circulate the changed sections. A brief that reflects what was true at conception but not what's true now gives false confidence and fails to protect the team.
If you do one thing from this post
Before your next project starts, write a one-paragraph problem statement that contains a number. It should describe who has the problem, what it costs them, and why the current situation is inadequate — without mentioning what you're going to build.
If the team can't agree on that paragraph, you're not ready to start. That disagreement is the most valuable thing you can surface, and the cheapest moment to surface it.
Next up: Post 2 — The Architecture Decisions That Will Haunt You (And How to Make Them Well)
