Expert Guide Series

What a Full Pre-Development Strategy Engagement Actually Includes

Most digital products that struggle after launch don't fail because of bad engineering. They fail because nobody agreed on what the product was actually for before a single line of code was written. The dev team built what they were told to build. The designers made it look good. And somewhere between the first meeting and the first release, the original thinking got lost, watered down, or quietly replaced by whatever felt urgent that week.

A pre-development strategy engagement exists to stop that from happening. And while the phrase might sound like a planning meeting dressed up in consultant language, what it actually involves is a structured body of work that sits between a product idea and the moment a development team starts building. It produces real artefacts. It surfaces real risks. It creates the kind of shared understanding that means everyone, from the founder to the front-end developer, is working from the same set of agreed truths.

At We Are Affective, we run pre-development strategy engagements as a dedicated phase of work. Clients who come to us with an idea but aren't yet certain of the problem they're solving go through this process before anything else. What follows is an honest account of what that engagement actually includes, what it produces, and why each part of it matters.

Pre-development strategy turns an unexamined idea into an agreed set of truths everyone can build from.

Understanding what the engagement covers in full helps to explain why each piece connects to the next, and why removing any single part tends to create problems further down the line.

Why Pre-Development Strategy Exists as a Distinct Engagement

A 2022 survey by UserZoom and Ipsos found that around 72% of product decisions were made without any user research informing them. That figure reflects how often teams move from idea to execution without ever stopping to interrogate what they're building or who they're building it for. The result is products that are functionally complete but emotionally hollow, tools that work in a technical sense but don't connect with the people they were designed for.

Pre-development strategy exists as a separate engagement because the questions it addresses are genuinely different from the questions design and development address. Design asks how something looks and feels. Development asks how it works. Strategy asks whether it should exist in this form at all, and if so, why this approach over another, and what the likely friction points are before anyone has spent budget on building.

Many clients arrive at this phase with a product concept already formed. The pre-development process starts earlier than that. It begins with the problem the product is meant to solve, and works forward from there, because a product without a clearly defined problem underneath it is really just a collection of features waiting to disappoint someone. Getting this right before development starts is far less costly than correcting it after.

The Research Artefacts WAA Produces

Research without documentation is just conversation. What makes research useful over time, especially when teams change and decisions get revisited, is the artefacts it generates. In a pre-development strategy engagement, we produce several interconnected documents that capture different layers of understanding about the user, the product, and the space it operates in.

Emotional Arc Mapping

One of the most consistently useful artefacts is an emotional arc document for each major user journey through the product. This captures how a person is likely to feel at each stage, not just what they're trying to do, but what emotional state they're probably in when they're doing it. A user booking a healthcare appointment is in a different emotional state to a user browsing a fitness app on a Sunday afternoon. The design and copy decisions that work in one context actively work against the other.

Brand Personality Documentation

Alongside emotional arc mapping, we produce brand personality documentation that establishes how the product communicates with people. This covers tone, visual language, and the overall character of the product's voice. Together, these artefacts mean that when the team moves into design and development, they have a shared reference point that keeps implementation decisions emotionally coherent and consistent with what the research revealed, rather than defaulting to whatever felt right on the day.

Build your research artefacts to answer the questions a new team member would ask six months from now, not just the questions the current team already knows the answers to.

Design that understands your users

We build app experiences around real user behaviour, not assumptions. Research, psychology-driven design and technical specs that turn users into loyal advocates.

See how we work Get started

No commitment

The Decision Log and Why It Matters

Products change during development. Features get cut, scope shifts, priorities move around. That's normal. What's less normal is keeping a clear record of why those changes happened, and what was considered before a decision was made. Most teams don't do this, and it creates real problems when a stakeholder asks six months later why a particular feature works the way it does, or when a new person joins and needs to understand the thinking behind a design choice.

The decision log we maintain during a pre-development engagement is a running record of every meaningful choice made during the strategy phase. It captures what options were considered, what the reasoning was, and what was ultimately decided and why. It's not a change log. It's closer to a rationale document, written in plain language that anyone on the team can read and understand without needing to have been in the original meeting.

A decision log means reasoning doesn't get lost when people, priorities, or team members change.

This matters especially when findings from research push back against what a senior stakeholder originally assumed. Having a documented record of what the research showed, what alternatives were considered, and what the team agreed to do as a result means that later challenges to those decisions can be addressed with evidence rather than memory. It also protects the development team, who shouldn't have to re-litigate strategic choices that were already worked through before they started building.

Date every entry in your decision log and note who was present when the decision was made. This small habit prevents a lot of "I don't remember agreeing to that" conversations later.

The Behavioural Risk Register

Every product carries behavioural risks. These are the points in a user journey where the psychology of the situation is likely to work against the product's goals. A checkout flow that asks for too much information at once. An onboarding sequence that creates anxiety by disclosing risks without balancing them against the benefits. A sign-up form that appears at the moment when a user's cognitive load is already at its peak.

Most development teams don't think in these terms, and that's not a criticism. Their job is to build what they're spec'd to build. The behavioural risk register bridges the gap between what's been specced and what's likely to happen when a real person, in a real emotional state, encounters that feature for the first time.

What the Register Captures

The register documents each identified risk with a plain-language description of the behavioural pattern involved, the point in the journey where the risk appears, the likely user response if the risk isn't addressed, and a recommended design or copy intervention. It also rates the risk by potential impact, so the team knows which ones to address first and which to monitor rather than redesign around immediately.

A description of the behavioural pattern creating the risk
The specific point in the user journey where it appears
The likely user response if nothing is done
A recommended intervention in design, copy, or flow
An impact rating to help the team prioritise

Transparency is part of this process too. Risks presented without any context about why the product is still worth building can overwhelm a team. The register always pairs each risk with its associated benefit, so the picture stays complete and decisions remain grounded in both sides of the evidence.

Alignment Sessions and How They Work

Strategy work produces documents. But documents alone don't create alignment. People do, when they're in a room together, or on a call together, working through the same material with the same level of attention. Alignment sessions are the structured conversations that move the strategy artefacts from documents into shared understanding.

We run alignment sessions at two points in a pre-development engagement. The first comes after the initial research phase, to walk the client team through what the research found and to agree on what it means for the product. The second comes at the end of the strategy phase, before handover to development, to confirm that everyone is working from the same picture of what's being built and why.

Who Should Be in the Room

The composition of these sessions matters. If only senior stakeholders attend the first session and the research team attends the second, information gets filtered and assumptions creep in. We typically recommend including people from across the client team, including product, design, and commercial leads, so that the findings don't have to travel through layers of interpretation before reaching the people who will act on them.

When research findings are likely to challenge existing assumptions, the sessions are structured to build broader internal understanding before addressing the most resistant voices directly. A finding that has been discussed and understood by six people in a room carries more weight than the same finding presented to one person who had already decided not to change course.

Send the relevant artefacts to participants at least 24 hours before an alignment session. People who've had time to read and sit with the material ask better questions and make better decisions in the room.

The Handover Pack a Dev Team Can Actually Build From

The end product of a pre-development strategy engagement is a handover pack. This is the document, or set of documents, that travels from the strategy phase into design and development. Getting this right matters more than almost anything else in the engagement, because a handover pack that's unclear, incomplete, or written for an audience of strategists rather than builders creates exactly the kind of confusion the whole engagement was designed to prevent.

A handover pack that a development team can actually build from contains several things. It includes a clear statement of the problem being solved and the user group the product is designed for. It includes the emotional arc documents and brand personality guidelines produced during research. It includes the behavioural risk register with recommended interventions. It includes the decision log, so developers understand the reasoning behind the spec they've been given. And it includes a prioritised feature list with the effort versus impact thinking made visible, so the team knows not just what to build but in what order and why.

Plain Language Throughout

Every element of the handover pack is written in plain language. Strategic thinking expressed in consultant vocabulary doesn't travel well. If a developer has to stop and interpret what a document means before they can act on it, the document isn't doing its job. We write the handover pack for the people who will use it, not for the people who produced it. That distinction sounds simple and is routinely ignored.

The pack is also structured so that individual sections can be referenced independently. A designer working on the onboarding flow shouldn't have to read the whole document to find the emotional arc for that section. The structure of the handover pack reflects how the work actually gets done.

Conclusion

A full pre-development strategy engagement is a body of work with a clear output. It produces emotional arc documents, brand personality guidelines, a decision log, a behavioural risk register, structured alignment sessions, and a handover pack written for the people who will build from it. Each part connects to the others, and removing any one piece tends to create gaps that show up later as confusion, rework, or products that miss the mark with the people they were built for.

The engagement also produces something harder to document but equally real. It produces shared understanding. When a development team starts work knowing not just what to build but why each decision was made and what the research behind it showed, they build better. They make better calls when they encounter the inevitable edge cases. They ask better questions when the spec doesn't cover a situation. They stay connected to the original thinking rather than drifting away from it under the pressure of deadlines and competing priorities.

None of this requires a large team or a long runway. It requires structured thinking, honest research, and the discipline to document what's been agreed before moving forward. If you're approaching a new product or a significant rebuild and want to understand what a pre-development strategy engagement might look like for your situation, you can start that conversation at weareaffective.com.

Frequently Asked Questions

A pre-development strategy engagement is a structured piece of work that takes place before any design or development begins, focused on answering fundamental questions about what a product should do and for whom. It exists because many digital products fail not due to poor development, but because the wrong decisions were made before a single line of code was written. Addressing these questions early prevents costly mistakes later in the process.

Strategy and design answer fundamentally different questions, and collapsing them together typically means design decisions are made before there is sufficient information to make them well. When the two stages are merged, research tends to be used to justify decisions already made rather than to genuinely inform them. Keeping strategy as a distinct engagement ensures the right questions are answered before creative work begins.

The engagement produces concrete, referenced documents that are directly usable by design and development teams, rather than vague slide decks filled with opinions. Examples include emotional arc documents that map how users feel at each stage of a journey, as well as artefacts capturing user needs, feature priorities, and strategic decisions with evidence behind them. Everything produced is designed to give teams something they can genuinely build from.

An emotional arc document maps how a user feels at each stage of their interaction with a feature or journey, capturing where confidence builds, where confusion arises, and where users feel rewarded. It provides design and development teams with a shared emotional reference point, so that interface decisions carry emotional reasoning alongside functional reasoning. These documents are particularly useful for ensuring that the final product creates the right experience at each step.

Decisions made during the strategy stage propagate through every subsequent phase of design and development, meaning errors at this point become increasingly expensive to correct. A feature prioritised incorrectly at strategy stage can cost weeks of design and development time to revisit, whilst a misidentified user need can cost even more. Investing in thorough strategy work upfront makes everything downstream faster and more confident.

The engagement involves the wider product team alongside the strategy specialists conducting the work, ensuring that decisions are well-documented and understood by all parties. The process is structured so that stakeholders have a clear record of why each decision was made, not just what was decided. This shared understanding helps avoid misalignment when design and development work begins.

This engagement should take place before wireframes, design systems, or any engineering briefings begin, as it is intended to shape the foundation upon which all subsequent work is built. Starting it any later risks design or development decisions being made without the grounding that strategy provides. The earlier the engagement takes place, the more value it delivers across the entire project.

Whilst the article focuses on digital products broadly, the principles apply wherever a team needs to make confident decisions about what to build and for whom before committing to design and development. The structured approach is particularly valuable for products where user needs are complex or not yet fully understood. Any team looking to reduce the risk of costly post-launch problems would benefit from this kind of early strategic grounding.