Back to Blog
Corrina Strebel

4 minutes read

A supplier’s journey from Project to Product mode

Corinna Strebel

Chief Product Officer

Chapter 1: Set the stage

The working strategy of my company is to establish teams that work in product mode rather than project mode. The transition from one mode of work to another brings certain challenges that need to be understood by all stakeholders who have a stake in the product, including the team that builds it.

In order to distinguish what are the main differences between these two modes of operation, take a look at the comparison of these two modes in a nutshell:

Project mode and product mode

It can be quite challenging for an IT consultant company to switch to this mode due to many things which need to be considered:

  • Is your company ready to work in this new kind of mode?
  • Do you have partners, aka clients, ready to let you work in this mode?
  • Is the topic you will be working on one that fits this approach?

Is your company ready to work in this new kind of mode?

For me, as a Product Person, there is mainly one tool I use to prepare the teams to work in Product Mode: Melissa Perri’s Product Kata.

Melissa Perri’s Product Kata
source: Melissa Perri’s website

If the company’s teams make use of the Product Kata, they are perfectly prepared since it gives you a structure on how to approach a current business problem that a development team can solve. The team will find out how to solve it following the experimental approach of the Kata.

The company’s management level is the second part which needs to be convinced of the product mode. This might seem easy since the management decided at first that this working strategy was the right one. However, you need to be aware that there are usually many departments involved, and every department needs to follow.

First of all the Sales department needs to be aligned. Because it all starts, and it can all fail with sales. If you sell the right product to the wrong customer, you lose. The wrong product in the right hands is again a lost opportunity. Therefore, your company’s salespeople are the first to understand what you’re up to sell and then find customers who want to buy exactly this product and nothing else.

Do you have partners, aka clients, ready to let you work in this mode?

During the sales process, it is essential to ensure that we, as a supplier, don’t just receive a requirements list. Most of the time, that is exactly what a client thinks we expect from them – so we get one. Such a situation usually leads to 3 different reactions: 

Either the team ignores the list and just starts with the exploration phase to figure out what exactly needs to be solved. 

Or the team negotiates every requirement with the client;

Or the team follows the requirements, stops thinking, and starts to create output no matter if it was proved to make sense or creates value.

Neither is only good nor only bad, but it is important to understand what’s happening and react to it, address it in time, and figure out what can possibly work for everyone.

At ProductDock, we are convinced that the product mode is the way to follow if you want to build successful software applications. Therefore, we execute small experiments that allow teams to learn quickly which solution brings value and which one to drop before too much money is burnt.

Some clients want to have a burndown chart to see how many backlog items have been resolved during an iteration. Instead, I recommend visualizing a daily budget burndown graph related to the team’s learnings. Every learning has its price. Clients and suppliers usually prefer investing only small budgets on learning instead of paying dearly. For example, clients often want to “try us” in a short amount of time-projects to mitigate the risk that they supposedly hired the wrong partner.

Their need and current condition to hire a supplier are high since they cannot build a product without a partner. The obstacle is that the client cannot know if the collaboration and quality will be good. Therefore the first step is to execute a short-term project with the supplier and measure if the expectations are met. After the short-term project, the client will have learned if a long-term engagement will make sense. Likewise, it is smart to invest this small amount of time and budget on a product idea early to determine whether there will be a market fit. But the obstacle might be that on the client’s side, the idea is set, the budget was set, the management believes already in a solution and doesn’t see a need to rethink.

Is the topic you will be working on one that fits the product-mode approach?

If the product idea leads to the desired outcome, and the client is 100% sure about it. Then, I recommend planning a proper project and executing it in a waterfall way with short feedback cycles. 

Suppose the client is insecure about the idea and desired outcome. It is time to do experiments and test your hypothesis.

Corrina Strebel

Corinna Strebel

Chief Product Officer

Corinna has worked for over 20 years with development teams and managed dozens of digital projects. Her role has changed significantly throughout the years, evolving from a Developer to a Project Manager, followed by a Product Owner, Agile Coach, and Product Manager roles, which all led her to her current role as the CPO at ProductDock. She became a fan of breaking up silos and fostering communication. She says that her secret ingredient turned out to be the experimental approach, aka Product mode, in which she coaches the teams she works with.

Related posts.