Product Mindset in an organization

  • Updated: 09 April 2024
  • 4 minutes
Article written by

"Product Work" is not just about methods, it's also a Product mindset!

To successfully implement a relevant Product Organization, we can attend trainings to learn the methods, read articles, etc. However, the foundation remains the Product mindset, the culture, and the people making up the organization.

Product Management, in addition to agility, are concepts that are increasingly being incorporated into traditional companies.

However, these companies face certain difficulties. For what reasons? What are the obstacles? How could we explain them?

Some answers here: traditionally, the core of these organizations is finance. Their objective: How to maximize financial gain? Everything is originally planned around this principle.

The budgets established in these companies have a very specific life cycle. Their control is crucial. Thus, these companies prioritize "having control over annual gains and costs."

Every year, at the same time, these large organizations, with vertical, pyramidal structures, set up budgets. Their goal is to ensure that everyone spends their share properly in order to confirm that the earned amount will be correctly invested year after year. This has certainly borne fruit for a long time, but it could be questioned now.

To frame all this, a set of committees is obviously put in place [The committee system is the term used to describe a decision-making procedure]. It is paced, unchanged for years, and very rhythmic.

Very few executives question these decision-making processes (or the corporate culture prevents them from acting on them) to seek the real added value of this committee system. Few are concerned with the influence of these numerous meetings on the time it consumes from their own employees, and on the expected and real value delivered by the committee system.

Examples

Let's take the example of company TOTO that wants to launch a new product. To do this, TOTO's executives hold a budget steering committee where they plan the necessary funds for the project and the associated schedule.

This will challenge the planning and budget to ensure that the gain is maximized and that money is not wasted.

Then, every month, management committees will ensure that the figures are in line with what was defined.

Another more operational example. What would be the added value, for middle management, to have mock-up validation sessions with CODIR members who are not aware of user problems or have no experience in UX/UI.

At all levels of the organization, it thus requires justifying every euro spent, trying to make sense of what we do. The goal is therefore to obtain more budget the following year or even satisfy a personal desire for influence within the company. Consequently, money might only be given to the "good students" or eloquent speakers, and not to products serving global strategic objectives.

It also happens that the true motivation of some is to satisfy the will of someone hierarchically above them. In this case, he/she acts without a real intention of wanting to improve a Product, to give meaning to it, and by extension to the employees or even the users.

To delve deeper into the topic:

If the subject interests you, I recommend reading the following article "Beware: This Hippo Kills Your Company!"

In some cases, budget approval is done in return for teams' commitment to projects, missions, specific features but not in exchange for solving user problems, for bringing something other than business value. In short, the budget is approved when teams commit to an output and not an outcome (even less an impact).


Do you know the concept of Beyond Budgeting?

Beyond Budgeting is a framework specifically designed for the financial sector. However, it is true that it could also be applied in other industries.

This concept, created by Bjarte Bogsnes, emerged around the same time as the Agile Manifesto. The Agile Manifesto is a text written by seventeen experts in computer application development, offering several Agile methodologies. (See the February 2001 manifesto)

This Agile approach is based on 12 principles: 6 principles of leadership and 6 of management.

The 6 principles of leadership

  • Purpose and values

Establishing a WHY to engage and inspire people around values, a purpose, a common goal, and not only around short-term financial objectives.
This principle can be implemented through specific workshops like the one offered by IDEO.

Design an Organization's Purpose Statement With This Tool

  • Autonomy

It is encouraged through self-organization, along with risk-taking, which is often at the origin of innovations. Consequently, the right to make mistakes also becomes a rule, since there are rarely true risks taken without the possibility of making mistakes.

  • Organization
    A pillar that can enable the development of leadership
  • Transparency

Here we mean transparency in the sense of opening up data. It is also about making all information visible to generate self-regulation, innovation, and learning.

With information being shared transparently, decision-making is shared and thus better accepted.

  • The focus on the end-user

When the focus is on the end-user, one can accept that a tool/product be discontinued or removed because it is not used enough. This is obviously very difficult for a team that has worked for months or years on this tool to see it stop without thinking "It's me being punished, it's my fault!"

  • Avoiding conflicts of interest

The 6 principles of management

  • Pace and goals

The framework recommends organizing our goals according to our business, the events of the year, our Product, and not only in terms of a calendar year.

Of course, we advise setting ambitious Product goals to provide a direction to aim for.

  • Avoid focusing on cascade plans and estimates (forecasts)

Is making estimates, plans, and forecasts not akin to creating "Many untested hypotheses based on unvalidated assumptions plotted in an uncertain future bearing no resemblance to reality" as Jared Spool says? We should avoid creating:

  • Plans
  • Resource allocations down to the last detail
  • Performance evaluations
  • Rewards: salary increases / personal bonuses: these rewards that generally generate comunal competition and serve only individual objectives.

When we talk about Beyond Budgeting, you might also hear about Capex / Opex. It's a way of considering the budget with two options:

  • Capex : Everything that can be capitalized: features from Product development
  • Opex: Everything concerning prerequisites, bugs, maintenance, all the tech enablers

To learn more about the concept of Beyond Budgeting, you can read "Implementing Beyond Budgeting: Unlocking the Performance Potential" by Bjarte Bogsnes

 

TAKE AWAY: the Product Mindset

To conclude, transforming into a Product organization also goes through, or even primarily, a change in mindset.

In my opinion, to change the organization at all levels, you should start by:

  • Establishing a vision (a WHY)
  • Setting up goals that rhythm the achievement of this vision
  • Making teams autonomous to achieve this WHY
  • Iteratively reviewing the way budgets are designed
  • Re-thinking the decision-making processes within the organization: the goals, expectations, and participants of each
  • Clarifying the values ​​of your company
  • Giving autonomy and transparency at all levels

Still, one of the keys to these principles remains trust: moving from a command posture to a balanced relationship between managers and employees, with a policy of transparency.

Everyone could thus thrive in their work, and ultimately, the entire organization would come out a winner.

To go further:

Sources

You'll also like