I was initially a project manager for a consulting firm, before finally converting into a fully-fledged product manager. Although to be fair, when I was a project manager, the things that I do for the client in need of digital transformation embodies what product managers have been doing without me realizing at that time. So technically I have more experience in the product management domain even stretching to the time before working as a product manager.
During my earlier time as a product manager, I happened to come across a framework shared by a colleague. The framework was shared by a Ghanaian-born British collegiate professor named Eddie Obeng. He suggested that projects can be grouped into 4 types based on the knowledge of what, and knowledge of how. What here means knowing what the problem is, meanwhile how means knowing how to solve the problem.
- The first project type is called Paint by Numbers. Projects inside this quadrant appear when the project collaborators know both the what and the how.
- The second project type is called On a Quest. Projects inside this quadrant appear when the project collaborators know the what, but lack the knowledge of the how. Like Dora the Explorer, we venture out with the hopes of getting to where we want to be.
- The third project type is called Making a Movie. Projects inside this quadrant appear when the project collaborators know the how, but do not know the what. The steps to make a movie are quite straightforward with the only difference being what story to adopt, but we will not know how good other people would rate it.
- And finally, the fourth project type is called Walking in a Fog. Projects inside this quadrant appear when the project collaborators do not know both the what and the how. Just like walking in a fog, we will not know where we should go and what we are going to get once we are out of it.
After reading up to this part, we must think that the most ideal project type is the Paint by Numbers ones. That is true because the uncertainty factors amount to minimum (as opposed to Walking in a Fog) and as long as we aligned our product to the agreed acceptance criteria, we should at some point experience the impact that had been forecasted prior to executing the project. In some situations, we do not even need to execute a major “reinvent the wheel” project and just create a task force to follow the recipe to solve the problem. However, these projects are so Ideal that situations such as this rarely appear at the beginning.
The definitely more Realistic project type is the On a Quest project. This is due to the fact that people or organizations would logically find themselves facing a problem, therefore the need to start a project arises. Now that we have a clear problem in front of us, the clear next step would be to find the right solution to it. There are a lot of frameworks that we can adopt to get to this solution, as long as we invest some of our resources into the discovery phase of the project. Conducting surveys, interviews, and down to testing prototypes to potential target customers can hopefully reduce the degree of uncertainty behind the project.
The other project type with one known factor is called the Making a Movie project. Despite knowing the answer to one of the two main questions, this is a project type that we should Avoid as much as possible. Imagine we have a tool that we feel is very sophisticated and valuable, but we and the people around us do not know what to use it for. The actual value of the tool will be very small compared to the amount of effort or budget spent to create or acquire it. This is not a good return on investment and I am pretty sure nobody wants to be in this predicament. But sadly, this situation exists in so many organizations throughout my experience. People tend to place big bets on very obscure stuff, force the idea to others so that they adopt it, and by the time they realise the mistake, they have already spent huge amounts of funds that cannot be recovered easily.
Now, imagine that there is a path towards certainty that everyone wants to head for. Certainty would of course mean having the knowledge of both axes. So if a project is already in the Paint by Numbers quadrant, then we do not want to move the needle to the other quadrants. But again, this project type is the most ideal state and other project types are more realistic for organizations to encounter.
Logically, if we have knowledge of one out of the two axes, then it will only take us one more step towards the desired certainty condition. However, this is not always the case. In fact, it depends on which axes we already identified. If we are On a Quest, we know what the problem is and we shall try our best to build or acquire the solution for that very problem. This means that we only need one more step to move from On a Quest to Paint by Numbers.
Should we encounter a project falling under the Making a Movie quadrant, do not think that it would only take us one step towards Paint by Numbers. Instead, we need to go back to the beginning which is Walking in a Fog. Because there is no point of having a tool with no clear purpose, therefore we should reassess what we want to achieve by building or acquiring something in the first place. Once we lock on a problem, we have reached the state of On a Quest. And once we are there, then we can consider ourselves as already heading toward the right direction.
In summary, the Eddie Obeng Project Type Quadrants concept explains that projects can be divided into 4 types based on the collaborator’s knowledge on what and knowledge of how. Knowledge of both is ideal, but realistically we know only one. If we only know the what, we should be a brainstorm session or two away from finding the best solution. However, if we only know the how, it is best to take a step back and reassess what it is that we see as a problem or pain point to be solved. Any type of project must have a clear purpose and that constitutes the what aspect in order to have a high likelihood of building or acquiring the right product.
This model of thinking is the one we use here at ARKETIPE as we always make sure that anything we build with our clients, solves whatever problems they face. Not only do we adopt this approach (out of a whole lot that we use as well), we also provide training to teams and organizations aspiring to one day build their own product development department. For more on this topic and other inquiries, please do not hesitate to reach out to us from our company website or our social media accounts at Linkedin and Instagram.
