<aside> 💡 A few people read this article I wrote on Medium and asked me to publish this document. I wrote this document to proactively mitigate the ‘frequently heard grievance’ from the Engineers in my team. It’s not meant to be a top-down document - I’ve updated this document based on feedback from the Engineers too.

</aside>

We are an empowered Product team

Empowered Product teams work towards a goal. They have the space to define the problems or areas of opportunities to reach the goal. They have the autonomy to come up with the best solution for the problem. We can call each of those solutions a ‘project’. However, it’s how we come up with the projects that differentiate an empowered Product team.

Let’s align on the terminology we use:

Projects

I used to hate the word ‘project’.

A typical project has these characteristics:

• The solution has been defined and just needs to be executed.
• As the solution has been defined, we assume that the problem has been understood clearly, and the solution has been thoughtfully chosen as the best one.
• A project usually has one goal: to launch or to complete the project. It’s output focused, not outcome focused.
• A project, more often than not, has a deadline.

Product teams shouldn’t be assigned projects to work on.

I said ‘used to hate’ - it’s because I accept the use of the word ‘project’ to describe something else, which I’ll get to later.

Goals

Goals are the outcome we want to drive by doing the work. A good goal should fulfil these criteria: