Avoid Conflict and Frustration: How to Manage Stakeholder Needs in Your Startup Project

Have you experienced situations of conflict and frustration after the start of a startup project when facing a misunderstanding of goals or vision in the team and partners?

I assume this has happened at least once, for the first-time founder or with a project at work. Typically, projects start with a great idea, sell that idea to the co-founders or team, start brainstorming, and build a prototype. You immerse yourself in the project, and the wheel of ideas and opportunities turns. The bad stuff comes a little later…

• You set deadlines that can't be met.
• You find out that no one knows what the actual scope of the MVP is, and arguments begin, or even quarrels.
• You start making pivots before the launch.
• Overspending becomes an obvious problem.

There is a way to mitigate these kinds of risks and undesirable situations. This way is to create a simple, but useful and robust project artifact - a document with stakeholder needs.

Let’s define who is stakeholders in a startup. You as a founder are a key stakeholder in the project and it’s important to start from yourself. Write down what you really want as a result, and why you are going to invest time into the idea. This will be a fundamental basis of the project's motivation and helps to find the right partners.

After that, as soon new participants join your circle of stakeholders grow within their needs - co-founders, investors, advisors, regulators, partners, and clients. It’s important to manage all their interests in a bit formal way by gathering needs into a document and making adjustments to stay aligned.

The key point is to have a tool that allows you to be on the same page with all people who trust you with the project and control all interest changes. It’s important to work with stakeholder needs regularly to stay focused and do the right things. Besides, there are more benefits that I describe at the end of this text. For now, let me explain how it works in practice.

How needs become the product

The needs document is a useful artifact that is living and changing along with the project ongoing. It’s important to maintain stakeholders’ needs regularly. In real life new requirements can appear and some insights while the project execution can affect ones that already exist. For example, your dev teams found some limitations, or some kind of risks happened.

In real projects it really hard to maintain the documentation to keep it clean and updated. Well, stakeholder needs are not an exception. To understand how to do it effectively and do not frustrate by bureaucracy let’s start with a document lifecycle explanation.

Original and upcoming needs

Initial needs and goals set by founders are the first steps and strategic points that have to be satisfied. You start a project with the definition of a kind of general features, revenue streams, markets, launch estimates, and so on. During the project, key stakeholders can populate new needs and constraints, obviously. It is top-bottom changes that define project strategy directly.

Discover and Gathering

However, you always have to discover more granular requirements and gather all related things to make a strong definition of what the people really want. So based on the previous stage, it is necessary to look around and go deeper into what else we have to include and what details we did miss. It can be a kind of research or a deep interview with stakeholders iteratively, here we draw our big picture of wishes and goals.

Clarifying and Commitments

Each item should consist of measurable outputs description and be linked with goals. The definition must be unambiguous and clear for all stakeholders. After you achieve agreements about what has to be done, it’s time to make commitments and pass them to the product backlog.

Decomposing & Execution

This stage will actually involve many execution processes - planning, development, design, QA, marketing, and so on - this is where the team rocks. But for high-level management, and in the context of this text, the key point is how to stay aligned with the real world of product creation and get feedback that can significantly influence stakeholder needs and further strategy. For example, there are a lot of situations when you will find that something can’t be implemented or real costs are much higher than expected before.

Updating

When needs are born, it's important to explain them as clearly as possible. But the updating phase is no less important, and you need to pay attention to it. When you going to update the needs document based on insights from the product development process, it can be difficult to negotiate and make changes. But it is only through this part of the process that you will have an aligned vision and mitigate the risk of resource depletion.

For now, you have an idea of how it works and how it can help. Let's get more practical and go through the 7 steps of building a quality stakeholder needs document.

A shortcut guide to getting started

1. Create the stakeholder map

This can be a spreadsheet or mind map with names, roles, and levels of influence on the project. You need to have a clear picture of whose interests you need to be aware of.

2. Interview stakeholders

In a startup, your first goal is to sell your idea to people who will commit to the project. The second important step is to deeply understand their motivations and expectations and capture them in structured requirements and conditions. So it's necessary to talk to all stakeholders and remember to focus on what they need, not how it should work.

3. Create a list of needs and constraints

Make a structured list of needs and constraints with basic groupings by category and names of people you have heard from about each item.

4. Identify items in the list for later reference and traceability

Later, when you create tasks and user stories, it's very useful to trace all activities back to a specific high-level requirement to manage them strategically. So give each stakeholder requirement (or constraint) some kind of ID to make it traceable in the future.

5. Add attributes as needed: categories, status, milestones, etc.

It's usually useful to do a review, say weekly, and have a way to quickly understand how things are going. So add general attributes to the items that will show you the status of the project.

6. Prioritize

Sometimes it's weird, but high-level prioritization can be really hard while you're building. Make a stop, look at everything, and be strong to set the focus on what is really important. You can use any kind of prioritization framework (ICE, WSJF, etc.) if acceptable, but I prefer to think about priorities using the idea of the theory of constraints described by Eliyahu M. Goldratt, which helps to focus on critical things in the right order.

7. Add external links to engineering requirements, design files, roadmap, financial plan, and others for traceability

If you already have something on an item in the stakeholder needs list - link it. You need to be able to easily understand where you have deliverables and where you have nothing. Later you will not have the option to dig every time.

I prepared a simple template in Notion to collect information from stakeholders. This template also includes Stakeholder Needs Description Template for elements inside to do it in a more systematic way: https://persistent-podium-beb.notion.site/b2df25e4eba24479bab01c19b197f094

In Conclusion

After all, you’ll have a kind of knowledge base that tells you about the people in the project and their intentions and needs. So what is the benefit of doing this now, when it may seem too difficult in the early stages? There are a few key things that will make sense:

1. To negotiate and close a deal with the founders and other stakeholders.
2. To get a clear understanding of why we are starting this project.
3. To help you stay focused and aligned throughout the entire project.
4. To provide transparency to your partners and investors.
5. To remember commitments and be able to give yourself the right answers to the question - “Does the project really going well?”