Modern software engineering organizations have already been heavily relying on strong product minded engineers, and this skill will only be more important in the future. You want engineers to make good product decisions both to scale as an organization and to increase developer satisfaction by giving them control over their own work.

However, if all decisions are made in isolation by different people, the resulting application will lack of conceptual integrity and it will either do not move the needle for business, or users get confused while using it.

By not having clear guidelines on what type of decisions can be made, by who and where, will lead to out of place discussions on meetings where the focus needs to be on something else. Important to emphasize the last point, because there is room to discuss these decisions (and everyone is encouraged to give feedback) but the place and the final say is important.

This is the framework I shared with my engineers to help them decide what decisions they can make freely and what decisions to bubble up.

Type of decisions

The type of the decision directly drives who can make it, and when. Before diving into them, I want to share one of my favorite product manager's favorite video that he consistently links since years because many product decisions, regardless of the type, are ultimately about focus.

What Focus means… is saying NO to something that—with every bone in your body—you think is a phenomenal idea. And you wake up thinking about it… but you say NO to it because you're focusing on something else.

Vision driven decisions (L1)

The first type of decisions are the ones that define where the application will land in the company's application portfolio. These high level decisions are important to have an application that works for the company. These are often decision that define the application unique selling points.

Who: The Product manager of the application / team is accountable for the results of the application, therefore these decisions are made by them. Normally, it doesn't happen in isolation, they consult with the development team, but the decision is theirs.

When: As they are critical for success, the goal is to make these decisions objective (data-driven) and documented in strategy documents. With other words these decisions are made when writing these documents.

Challenging these decisions are entirely possible, but it needs to be outside of day-to-day activities (e.g., not an ad-hoc discussion on a daily meeting). Go prepared on why the strategy should be changed, and think of the focus above.

The assumption is that all other type of decisions are inline with the strategy.

Strategy aligned, hard to change decisions (L2)

The second type of decisions are the ones where all options/solutions are aligned with the strategy but it is hard to change the decision later. These decisions will bring us to the right direction one way or another, but the cost will have a significant impact on the deliver / project schedule. Usually, these decisions also have an impact on future development, and can also be architectural (technical) decisions that influence user experience.

The second type of decisions will bring us to the right direction one way or another (all options/solutions are aligned with the strategy), but it is hard to change the decision later (cost will have a significant impact on the deliver / project schedule). Very often they are architectural (technical) decisions that strongly influence user experience.

Who: Make this decision on the group (i.e., project team) level, with final words from the technical, product and project leads.

When: Make a separate meeting for discussing them, and support the discussion with RFCs (including pros and cons). It is also important todocument the decision.

Strategy aligned, easy to change decisions (L3)

The last type of decisions are the ones where all options are aligned with the application strategy and they are easy to change. There are many L3 decisions, and the delegation of these what makes companies to scale. Very often there are various guidelines (UI design, writing, etc) that helps engineers to get the final result for first, but ultimately the guide is guide is to make these decisions with the end user in mind. Feel free to review the solution by AI or ask feedback from experts, if you would like to.

Who: Whoever is working on a task.

When: During implementation.

With frequent alpha releases, people will provide feedback and you can iterate on the final solution.

Prioritization

There is a special type of decision that was not covered above. So far we only talked about if a feature should be in or out, and how it should look like. Prioritization is about when it will be implemented.

When something is implemented (i.e. whether or not something “is prioritized”) is ultimately a project management decision. I have a good template that I will share in an upcoming post, but which feature is in which product milestone is a joint agreement between product, tech and project leads.

This is about the the final say only, but the best if all team members can join the discussion.