Stakeholder Identification Decision Wizard for Startup Software Engineers
A branching wizard that helps individual contributors on early-stage software teams identify the stakeholders behind a feature — including the silent disagreers who block launch.
Find the four people who can quietly kill your feature before you ship it
On a small software team, every stakeholder you didn't ask is a future blocker who has already made up their mind.
Engineers on small software teams often skip formal stakeholder identification because the company is twenty people and 'we all know each other.' That's the trap. Knowing each other socially does not translate into knowing who has a stake in your feature. The wizard below is a five-minute self-check before you start building.
It's structured around the silent disagreement pattern: the goal is to surface, before code lands, the people who will say something different in approval than they would have said in design — usually because they were never asked.
Step 1: Who has a stake in the outcome?
0 / 4- Who asked for this feature, in writing?
- Whose KPI moves if this feature ships?
- Whose KPI is unaffected but who will get questions about it?
- Who supports customers who will use this feature first?
Step 2: Who has approval authority you don't see?
0 / 4- Will any external system require legal, security, or privacy review before launch?
- Will this feature touch billing, auth, or data export — and is the owner of that surface aware?
- Is there a customer-success team who will need to brief customers before launch?
- Does the founder or CEO have a public position about this product area?
Step 3: Who's silently affected?
0 / 4- Whose existing workflow does this feature alter, even subtly?
- Who currently solves the problem this feature replaces — and have they been told?
- Who maintains the surrounding code, and have they been pulled into design?
- Who currently fields questions about this product area in support tickets?
Wizard outcomes
Match your tally of 'yes' answers across all three steps to one of three outcomes.
Outcome A — 0 to 3 'yes' answers. Either this is a genuinely small change (refactor, internal tool, dev-only feature) or you haven't thought hard enough. Re-read with someone outside engineering before deciding it's truly outcome A.
Outcome B — 4 to 8 'yes' answers. Standard feature. You have between four and eight stakeholders to actively manage. Build a one-line note for each: who they are, what they care about, when they'll see this. The most common failure mode at this scale is not identifying these people — it's identifying them and then forgetting to brief them. Schedule the briefings before code lands.
Outcome C — 9+ 'yes' answers. This is not a feature. It's a small project, and it deserves a charter, a stakeholder register, and at least one explicit decision-maker. The instinct will be to keep treating it as a feature because the team is small. Resist. Apply the startup software charter template and re-run this wizard against the formal stakeholder register.
- Day 0Run the wizardFive minutes. Before any spec writing.
- Day 1Brief the silent stakeholdersAnyone surfaced in Step 3 gets a five-minute conversation. Most will say 'thanks for telling me' and move on. The few who don't are the silent disagreers.
- Day 2–4Spec and designSpec includes a stakeholder line: who has been briefed, who has open concerns, who has approval authority.
- Pre-launchFinal stakeholder checkBefore launch, scan the spec's stakeholder line. Anyone with open concerns gets a final ping. Anyone you've forgotten gets added now, not after.
| Stakeholder class | Identify before | Conversation cadence | What to ask |
|---|---|---|---|
| Founder / sponsor | First commit | Weekly | What outcome would make this worth it? |
| First customer | First demo | Bi-weekly | What would make you stop using this? |
| Ops / on-call owner | First deploy | At every release | What would make this unrunnable? |
| Investor / board | First quarterly | Quarterly | What signal would change the funding decision? |
Five minutes upfront, one round of five-minute briefings — for most early-stage software features, this is the entire stakeholder identification process. Skip it and the cost is paid in the launch week, when surprises are most expensive and least recoverable. For the team-level companion to this individual practice, see the startup software charter template.