We need business agility in our high-tech Product company

What is business agility? Try google the definitions of  “Agile”, “agile” and “agility” and get confused. In this post we’ll use the simple definition:

Becoming agile (having business agility) is the goal – Agile frameworks / methods like Scrum, Kanban etc. are among the means to achieve business agility.

The nature of “business agility” is highly dependent on the specific business context. In this post we’ll assume the context of a high-tech Product company.

Spoiler alert: Implementing Agile frameworks / methods is the easy part and only a fraction of the larger challenge reaching for business agility.

Before we dive-in, let’s recap the raison d’être for a high-tech Product company. Inspired by Marty Cagen in EMPOWERED:

the Product company Innovates Products the customers love, yet work for the business. 

Agility for the high-tech Product company is thus very much about Innovating the right Products at the right time. What good is it, if you are able fast to develop and deliver a Product using some Agile delivery framework, if it is the wrong Product? The various Agile frameworks have proven effective when it comes to the development and delivery of already identified solutions. The part Discovering what solution to develop (given the business/customer problem) is however outside scope of the Agile Delivery frameworks as outlined in dual-track agile.

You’ll easily find a lot of organizations and “coaches” ready to provide education / training / certification in the various flavors of Agile for your employees. Do get your employees trained in relevant Agile frameworks (you’ll need it), but understand this is not your main concern and not what will drive your “Transformation” towards strong Product Innovation.

Let’s briefly have a look in the rearview mirror to understand where we came from and how we classically have approached complexity.  Following that we’ll try to understand what the best-of-the best Product companies do. From here we’ll address the transformation towards (better) business agility and finally some anti-patterns to it.

If you do not have the time or patience, you can jump directly to the conclusion.

The historical roots

Max Weber (1864 – 1920) stood father to the Bureaucratic / Mechanistic school based on strict functional hierarchies and rules. Management and employees are supposed to work as efficient machines.

Frederic W. Tailor (1856 – 1915) invented Scientific management based on Time studies and Functional management.

Henri Fayol (1841 – 1925) is known for the Administrative School promoting a limited Span-of-Control and a flat Hierarchy (yes – inconsistent with the above). With responsibility follows authority.

The typical spine-reaction to increased complexity in classically structured organizations is stricter Project governance, more control bodies, stricter and increasingly complex Project process prescriptions, more checklists, more reporting, more detailed planning – even for stuff that cannot be planned. Decisions are delayed, needing to travel up and down the hierarchies. The odd thing is that the biggest decisions are taken far away from where the biggest insight and information is. A bit sarcastically some describe this as “HIPPO” meaning the Highest Payed Persons Opinion. 

Projects are classically defined as ad-hoc teams in a matrix structure which in itself generates bureaucracy, friction and inefficiency:

Classic matrix organization

This more-of-the-same approach leads to an increased bureaucracy, leading to inner inertia, making it harder to respond to changes in technology and market conditions.

In these “classic” Product organizations you’ll typically find Projects run with a command & control mindset using e.g., bloated methods like PRINCE2(C) or some home-grown “project-model” having grown fatter and fatter over the years.

This reduced ability to maneuver impedes the Innovation power. And to makes things even worse – you’ll see employee motivation and satisfaction drop in a fierce attempt to manage the increased bureaucracy.

This inner inertia and way of working has taken years to grow momentum. Radical changes are hard and full of risks, so unless the given high-tech Product company feels a strong sense-of-urgency, it’ll probably not act decisively. To “tick the Agile box” some high-tech Companies introduce e.g., SAFe (we’ll return to SAFe under anti-patterns) in parts of the organization.

Business agility - what the best Product companies do

Some of the most well-known high-tech Product companies (Tesla, Apple, Google, Netflix, Amazon, Pixar, Über ..) have at least one thing in common: they are consistently strong Product Innovators taking technology very seriously. Take Tesla as an example. Tesla is able to make changes at a rate no other car manufacturer can – not even close. A Tesla is “a computer on wheels”; not a car with built-in computers.

This post is  a synthesis of e.g., some of Claus’ inspirational sources combined with Claus’ experience, condensed in the Innovation Power wheel below.

Disclaimer: There is no one-size-fits-all Silver Bullet or Snake Oil cure covering every conceivable high-tech Product company. 

Business agility

Product Culture

“Culture” is something abstract but most people agree that “culture” is very important. Culture is not a goal set to drive behavior. In fact, culture is the consolidated result from your organizations behavior. We’ll here refer to Marty Cagan in EMPOWERED page 372 for a short version of Product Culture and purpose:

Good leaders focus on culture and purpose because culture drives innivation and performance. The greatest capital of an organization is its people. To innovate, people need autonomy and meaning.

The only viable way for you as a leader to work for the good Product Culture is to show the way with your own behavior. Much like being a parent; it is not what you say that matters. It is what you do. Haven’t we all experienced leaders Talking the Talk but not consistently Walking the Talk?

Organizational structure

The organizational structure of the strong Product company, the roles and mindset  within it, is optimized for Innovation. See also Servant Leadership.

Team Structure

The best Product companies have a Product Mindset using Product Teams – not a Project Mindset using Project teams. Let’s start comparing a Product Team with the classic Project Team.

Project Team

    • is an ad-hoc allocation of people from the functional silos, thus being dissolved when the project is done
    • is tasked with the development of a given and specified solution thus focusing on Output
    • cannot be held responsible for the Outcome (business result) for the simple reason that the Team was given the solution to implement
    • perceives itself as a group of mercenaries with specified tasks to execute

Product Team

    • is stable and cross-functional
    • is autonomous (though some dependencies will exist in practice) 
    • is self-organized
    • is given a (hard) business / customer problem to solve
    • is empowered to Discover the right solution to the problem
    • is measured & held accountable for the Outcome (business result)
    • perceives itself as a group of missionaries with a cause

Key roles and responsibilities

The relevance for specific roles is of course dependent on the specific organization and its business context. The high-tech Product company will need a CTO (Chief Technology Officer) and a Head of Product which some time could be a CPO (Chief Product Officer). Ask 10 people and you’ll get 10 different opinions on the responsibilities. You’ll find  descriptions (plus descriptions of a number of other relevant roles) of the CTO, CPO and PM in Marty Cagan’s INSPIRED:


The CTO being the Head of Technology has at least six major responsibilities (ref. INSPIRED page 88):

    1. Organization – building an excellent technology organization with a strong management team committed to developing the skills of your employees.
    2. Leadership – representing technology in the overall strategic direction and leadership of the company, working with other company executives to help inform direction, M&A activity, and build / buy / partner decisions. 
    3. Delivery – making sure the organization can rapidly, reliably and repeatedly deliver quality product to market.
    4. Architecture – making sure the company has an architecture capable of delivering the functionality, scalability, reliability, security and performance it needs to compete and thrive.
    5. Discovery – making sure that members of the senior engineering staff are participating actively and contributing significantly throughout Product Discovery.
    6. Evangelism – serving as the company spokesperson for the engineering organization, demonstrating leadership in the community with developers, partners and customers.


The CPO being the Head of Product has at least four major responsibilities (ref. INSPIRED page 79):

    1. Team Development – developing a strong team of Product Managers and Product Designers is the single most important responsibility.
    2. Product Vision and Strategy – is what drives and inspires the company and sustains the company through ups and downs.
    3. Execution – is a matter of getting things done thus needing an expert on modern forms of product planning, customer discovery, product discovery, and product development process.
    4. Product Culture – in the strong sense means that the teams understand the importance of continuous and rapid testing and learning.


PM is here short for Product Manager (not to be confused with a Project Manager). The PM is a very challenging role in the need of at least four key competences (ref. INSIPRED page 41):

    1. Deep knowledge of the Customer – meaning the need to become an acknowledged expert on the customer: their issues, pains, desires, how they think, how they work, and how they decide to buy. Of course the PM must also be an undisputed expert on your actual product.
    2. Deep knowledge of the Data – being comfortable with data and analytics.
    3. Deep knowledge of your Business– understanding how it works and the role your product plays in your business. This includes knowing who the various stakeholders are and especially learning the constraints they operate under.
    4. Deep knowledge of your Market and Industry – covering not only your competitors but also key trends in technology, customer behaviors and expectations and following the relevant industry analysts. The PM may be supplemented with what are called domain experts or subject matter experts.

Note that a PM is far more than the Scrum Product Owner (PO). See e.g., Marty Cagan’s blog post The CSPO pathology. A PM is encouraged to receive PO training because part of the job as PM is the administration of the Product Backlog.

Servant Leadership

Realizing that the core value-creating entity is the Product Team, the Leadership / Management  structure must ensure the best possible foundation for the Product Teams to perform. This mindset is often called “Servant Leadership”. This is Claus’ definition of “Servant Leadership” :


Aim to motivate through a common North Star bringing life to the purpose, rationale and meaning for us being here. The overall Business Strategy and Product Vision facilitate the Product Teams to act (fairly) autonomous, yet stay aligned on the bigger picture.

Provide direction for the Product Teams through the Product Strategy and (hard) business / customer problems for the Teams to solve.


Enable (real) empowerment having the Product Teams decide the right solution to a problem through Product Discovery – and keep the Product Teams accountable for the Outcome (business result). Demonstrate trust and provide a psychological safe environment fostering an Innovation culture based on fast failure and learning through experiments.


Support the Teams and individuals to grow and be successful, be available, ensure active and fast removal of impediments, coaching (a key but often overlooked responsibility) of Teams and individuals and helping Teams to coordinate. Just to be clear – this “coaching” dimension is far more than understanding a given Agile framework.

This could additionally include facilitation of Communities of Practice across Product Teams.

To summarize – the overall purpose of Servant Leadership is thus to provide a solid Foundation upon which the network of Product Teams will thrive.

Foundation for business agility

Minimum Viable Governance & VC-style funding

A classic Project is based on the assumption that the solution is known and specified thus having an up-front Business Case followed by a tight tolerance-based governance focusing on delivering the Output within the boundaries of the Business Case.  

Contrast this to Product Teams. What initiates work in a Product Team is a (hard) business / customer problem. At this point in time the right solution to the problem remains to be found. Attempting to make a Business Case not yet knowing the solution clearly makes no sense. What does make sense is that a Product Team need to show progress in exchange for which it’ll seek funding similar to a start-up seeking Venture Capital. See also the comments on OKR (Objectives and Key Results) under Transformation Execution.

Business agility - Venture capital

Note that this is in fact far more challenging than the classic Project “just” having to maneuver within agreed boundaries.  The Product Team need really to have its qualitative and quantitative data and insights in place regarding market and technology plus validated experiments for it convincingly to acquire funding. In the early stages progress will be in the form of insight / learnings.

All companies, also the super strong Product companies, need a certain level of governance “glue”.

The trick is to keep this governance (bureaucracy) at a Minimum Viable level.

Business agility - Governance glue

Minimum Viable Process prescription and a rich pick & use Buffet

In the classic Project setup you’ll often have a highly prescriptive and layered “Project model” with Project governance process on top and below a set of Project execution processes. Some organizations have even ISO 9001:2015 certified their “Project model” thereby cementing their focus on process compliance.

The mindset behind the process-universe supporting Product Teams is radically different. The main focus is here to provide a rich pick & use process Buffet and keep the process prescription at a Minimum Viable level. This Buffet embodies the collective knowledge developed over time. Here you’ll e.g., find the organizations take on best-practice on Continuous Discovery , Team Topology etc. If you’ve decided to use Scrum Masters this would also be the place to share the organizations best-practices in the field. And no – here you’ll not find massive process prescriptions just for the sake of pleasing ISO 9001:2015.

Part of Servant Leadership could be to facilitate Communities of Practice (CoP) across Product Teams with the purpose of sharing and developing knowledge. CoPs would naturally contribute to the process Buffet. A key trait of the strong Product organization is exactly knowledge sharing and development.

Dual-track Agile

Jeff Patton & associates posted the article Dual Track Development is not Duel Track back in 2017. It remains fully valid with the message that

discovery work focuses on fast learning and validation

development work focuses on predictability and quality

discovery and development are visualized in two tracks because it’s two kinds of work, and two kinds of thinking

The two tracks exist within the same Product Team, in parallel and interact with each other. How you in practice make it happen in your Product company will also be input to the Buffet.

Technology Excellence

Cut to the bone, technology is the product! Solid engineering practices and deep technology expertise is of course a must during both Discovery and Development. 

One thing that can really kill your business agility is poor engineering practices resulting in e.g., global dependencies. No matter the engineering domain, your engineers must follow the lead from software development ensuring de-coupling via encapsulation behind stable interfaces. More on that in a future post covering e.g., Digital Twins and Model-Based Systems Engineering etc.

To repeat Marty Cagan

We want to Innovate Products the customers love, yet work for the business. 

If you do not deliver a Product matching your customers quality expectations, they’ll definitely not fall in love with it. Without technology / engineering excellence, you’ll become irrelevant.

Transformation towards (better) business agility

Here definitely no silver bullet applies. You need to find a solution that works for you in your unique Product company context. But – the challenge is in many aspects similar to that of Innovating a new Product and bringing it to market:

    • You’ll need a compelling and strong Vision / North Star for your (improved) business agility
    • You’ll need a transformation Strategy guiding you towards the Vision
    • You’ll need to Execute your Strategy
Business agility - Leadership

As pinpointed under Product Culture, you as a leader need consistently to show the way taking your own medicine. Do not  approach the Transformation “the old way”, inconsistent with the Vision you are promoting. Here is your chance to show what Servant Leadership is about.

As we’ll address below, what can and should be delegated is responsibility of finding the right solutions to the problems outlined in the Transformation Strategy. What cannot be delegated is the ownership of the Transformation Vision needing a clear ownership in the C-team.

Transformation Vision

Use the time needed really to think-through your Vision – the future situation you want to have – and then stick to it. In Jeff Bezos’ words Be Flexibly Stubborn:

We are stubborn on vision. We are flexible on details…. We don’t give up on things easily. If you’re not stubborn, you’ll give up on experiments too soon. And if you’re not flexible, you’ll pound your head against the wall and you won’t see a different solution to a problem you’re trying to solve.

A couple of check-questions:

    • is your Vision compelling, inspiring and empovering?
    • is your Vision easy to communicate and understand?
    • last but not least – have you taken the time and effort to involve your organization making it OUR Vision (though owned by the C-team)?

Transformation Strategy

Your Strategy for how to reach the Vision is based on a series of assumptions of the problems to solve on the way. Again – very similar to your Product Strategy painting the way towards your Product Vision.

When your Strategy meets reality, its assumptions will be pressure-tested, and some assumptions will fall flat to the ground. This is where we need Bezos’ flexibility internalizing the new learning resulting in updated assumptions and problem-definitions. The Vision remains but we’ve updated our approach to reach it.

A good rule-of-thumb is to start small with e.g., one Product Team in one Product area and gain insights through experiments.

“Transformation” is about people. Some will pop quickly with a full buy-in, some will need time to pop and some will never pop not finding this new way of working attractive for them.

Being the ones initiating and owning the transformation, the C-team will and should not oppose it.

The employees going to be trusted to work in modern and highly empowered Product Teams are likely to pop quickly for the simple reason that this will improve the foundation upon which they work.

The most reluctance is expected among middle-management because silo-management will have to adapt to new role definitions and expectations.

Business agility - Popcorn and people

A couple of check-questions:

    • did you generate enough insight enabling you to decompose your vision into a consistent set of problems to be solved?
    • are you initially throwing a small stone in the lake, or are you planning for a splash with big rock?
    • did you acknowledge the popcorn-effect?
    • did you carefully decide on the topology of the Transformation Team, and did you clearly align expectations with this Team?

Transformation Execution

In the same way we give Product Teams (hard) problems to solve, we need to give one or more Transformation Teams problems to solve as outlined in the Transformation Strategy. Like the Product Team, the Transformation Team will initially have its primary focus on the Discovery of the right solution to the given problem. 

Empowerment does not mean encapsulation of information. Actually the exact opposite. We need full transparency. One well-proved method is the use of OKRs (Objectives and Key Results). See e.g., John Doerr’s Measure What Matters.  A short definition of OKR:

The definition of “OKRs” is “Objectives and Key Results.” It is a collaborative goal-setting tool used by teams and individuals to set challenging, ambitious goals with measurable results. OKRs are how you track progress, create alignment, and encourage engagement around measurable goals..

Fully understanding and using OKRs is a big topic in itself. A future post (update: look here) might dig into the universe of OKRs. Here we’ll limit the coverage to a few bullets:

    • the aim is to have a hierarchy of OKRs ensuring a consistent link between top-level / strategic OKRs and Team OKRs
    • the Objective part (the Problem to be solved given to the Team) is described in qualitative terms
    • the KR (Key Results) is a quantitative and time-bound measure. The KRs are used to measure and communiucate progress.
    • let the Team suggest the KRs (have 2-3 KRs per Objective)

Some of the anti-patterns reaching for business agility

As little change as possible!

Fake business agility

We want to change as little as possible but enough to convince ourselves, that “the Agile box can be checked” and that we’ve “scaled it” throughout the organization.

SAFe has attracted many executives making it a wide-spread framework because it can be seen as a convenient add-on to the existing organization. 

Marty Cagan has clearly made comments on SAFe in the Revenge of the PMO and so has Steve Denning in Fake Agile:

A particularly unfortunate form of “branded Agile” concerns scaling frameworks. A worrying variant is the Scaled Agile Framework or SAFe. Essentially this is codified bureaucracy, in which the customer is almost totally absent. It is now pervasive in large firms because it gives the management a mandate to call themselves agile and keep doing what they have always done..

SAFe may of course happen to be exactly what best serves you, but make sure that this is the case. Do not chose SAFe with the argument that “we can become agile with only small changes”.

We need it yesterday!

What is problematic with the situation below?

Business agility anti-pattern
    • the CEO clearly lacks the understanding and ownership of what business agility is for his high-tech Product company
    • the CEO believes the message that it is primarily about having his people trained in Agile frameworks (nice to be able to buy a solution to the problem)

To be fair – a solid insight and training in good solid Agile practices tailored to the company’s context  is important. What the CEO misses is that this is the easy part.

Note: Be aware of the CSPO Pathology


Reality check: If Amazon started showing interest for your high-tech Product market, would you sleep well at night?

If the answer is no, then it is most likely too late for you to do much about it. Not “only” the start-up in a rented garage down-town will aim to disrupt you – mega players like Amazon having maintained the start-up mindset could eat you for breakfast if you fall asleep.

What differentiates the best high-tech Product companies from the rest is the Product Culture anchored in Product Teams and in the organizational foundation upon which the network of Product Teams operate. 

Getting strong on Product Vision, Product Strategy and Product Management is where you’ll find the really tough challenges.  Getting your people trained in relevant “Agile Frameworks” is important but only a small fraction of the bigger challenge.