Category: Ikke-kategoriseret

Posted on

Renewable Tech – the journey towards a strong Product company (part 2)

Renewable Tech part two

This is part 2 in the series of posts discussing the journey towards becoming a strong Product company. Here we’ll focus on the Vision as formulated by RT’s executive team.

Recap from part 1

In part 1 the strategic context of the hypothetical company, Renewable Tech [RT], was outlined. From currently being a provider of customer-specific solutions, RT’s strategy is to undergo a transformation towards becoming a market-leading product company within renewables technology. Referencing Marty Cagan:

We want to discover and deliver products that our customers love, yet work for our business.

We balance four product risks in Product Discovery making sure that the product is

    • valuable for the customer
    • usable for the customer as intended
    • feasible for us to build
    • viable for our business

Marty Cagan, Silicon Valley Product Group

Note that most of RT’s (coming) products have a physical dimension, though some purely digital. Product Discovery and Delivery is not done by having a working prototype. It is done when serial production (using relevant Industry 4.0 elements) runs. As quoted earlier:

The factory is the product.

Elon Musk @Twitter January 2nd 2021

The Vision

RT’s executive team is determined to learn from and eventually become among the few best high-tech Product companies. RT has thus decided to seek guidance from SVPG – Silicon Valley Product Group – because this is what comes closest to a consolidated insight into the workings of the worlds best high-tech Product companies. 

RT has found, that the overarching and common strength among these best-in-class companies is their highly developed Product Culture as described by Marty Cagan: 

    • Culture of experimentation
    • Culture of open minds
    • Culture of empowerment
    • Culture of technology
    • Culture of business- and customer-savvy teams
    • Culture of skill-set and staff diversity
    • Culture of discovery techniques

We’ll return to the Product Culture.

The corner-stone in RT’s (coming) ability to Discover and Deliver high-tech renewables products that customers love, yet work for the business, is the network of Product Teams.

Teams

As described earlier, these are the general characteristics of a 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

Though some experiments with DevOps (you build it – you run it) on purely digital products have been run, the predominant approach to complexity in RT is currently the classic project with the classic project organization:

    • 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

The current auto-pilot reaction to a problem in RT is thus to pull-out the known tool from the toolbox: a project. This is a sensible modus operandi when talking customer solution projects. Approaching innovation with a project mindset is highly counter productive.

RT’s executive team realizes that coming from a project mindset with ad-hoc project teams to a product mindset with stable product teams is a major challenge. But – the executive team is stubborn on the vision – it is a fundamental prerequisite for RT’s ability to become a strong Product company.

Leadership and organizational structure

The aim for RT’s executive team is to have an organization filled with and working for missionaries. To quote Gary Hamel:

In a bureaucracy human beings are instruments, employed by an organization to create products and services. In a humanocracy, the organization is the instrument – it’s the vehicle human beings use to better their lives and the lives of those they serve.

Gary Hamel

The leadership / management role

RT’s executive team has reached the same conclusion as Marty Cagan:

We do not need less management – we need better management.

Marty Cagan, Silicon Valley Product Group

“Better” means the ability to optimize the conditions under which the network of Product Teams operate. In essence it is about Servant Leadership being able to provide meaning, direction, (real) empowerment and support.

RT is not dismantling the functional “silo”. RT is redefining it and the leadership / management roles within it. Remember that one of the critically important responsibilities of Servant Leadership is to coach the professionals, with reference to Bill Campbell:

Coaching is no longer a specialty; you cannot be a good manager without being a good coach.

Bill Campbell

The leader / manager with direct responsibility for employees must have and maintain sufficient domain insight to be capable of providing coaching and helping the individuals to grow.

RT’s executive team have found Marty Cagan’s definition of the CTO, CPO and PM roles in the strong Product company to be a solid starting-point:

CTO – Chief Technology Officer

    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.

      Marty Cagan

CPO – Chief Product Officer

    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.Marty Cagan

PM – Product Manager … not to be confused with a Project Manager

    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.Marty Cagan

Team Empowerment

Highly empowered teams is not the same as the Product Teams are free to decide everything. With empowerment comes conditions agreed with leadership / management. Because RT’s business is based on applied technology, sharp strategies on technology is of vital importance. 

It is a leadership responsibility (with the top-level responsibility anchored with the CTO) to maintain and communicate these technology strategies under which the Product Teams operate. It can and will happen that a Product Team discover a solution outside the perimeter of the technology strategies. In this case they’ll of course approach relevant technology leadership for a dialogue.

Organizational structure

RT’s executive team wants to boost the Product Culture with Product Teams as much as possible thereby boosting RT’s innovation power. This calls for an organizational structure with Product Teams serving the (real) customers; not serving internal stakeholders. This is the out-line structure as defined by RT’s executive team:

Organizational principle

What is important to note here is, that the Product Teams in “Own product development” have a direct and frequent dialogue with selected (potential) customers; not via Sales / the SBUs.

This is not the same as the Product Teams act in isolation. In fact, the Product Teams (and especially the Product Manager in the team) have an obligation and interest in understanding the constraints under which the team’s business stakeholders operate. To repeat the very important point: the Product Teams serve the customers – not the business.

Product Team topology

Some of RT’s (coming) products can be held within one Product Team. Other products will need a network of Product Teams collaborating on the product. As expressed above, one of the responsibilities of Servant Leadership is to facilitate the smooth collaboration and communication in the network of Product Teams.

Foundation for business agility

Exactly how a given Product Team is designed, is a leadership responsibility, derived from RT’s generic Product Team template:

    • Product Manager.
      Main responsibility: Solutions are valuable and viable. Includes the Scrum PO role owning the Product Backlog – but is much more!
    • Product Designer.
      Main responsibility: Solutions are useable.
    • Engineers / developers.
      Main responsibility: Solutions are feasible.
      Tech Lead: A senior level engineer having taken additional responsibility.
    • Scrum Master / Delivery Manager.
      Could be the Tech Lead. Some teams do not need a Scrum Master at all.

When talking products with a physical dimension, and thus production, the Product Team of course also need to have production technology competences on-board. Remember: the Product Teams have the full end-to-end product accountability.

How the intended Product Culture will support the vision .. with anti-patterns

With reference to the Product Culture outlined at the start, the intention below is to illustrate its link to the vision. You’ll also find examples of how not-to-do.

Culture of experimentation

The use of carefully designed and disciplined run experiments, testing assumptions is key to gaining new insight and learning. The principle is – fail fast, learn fast. For this to work an atmosphere of trust and psychological safety is fundamental. 

Antipatterns

Failing experiments is perceived as the team is failing. This will definitively kill the teams motivation. Another efficient way to kill a culture of experimentation is to demand the use of the company’s “project model” used for customer projects. 

Culture of open minds

The mindset is that we’re all innovators capable of bringing innovative ideas to the table. Having an open mind allows for normally not obvious sources to contribute.

Antipatterns

Only a selected group of people are expected / invited to contribute with the brilliant ideas.

Culture of empowerment

This is nicely captured by Gary Hamel:

Leadership is not defined by the exercise of power but by the capacity to increase the sense of power among those led. If you’re a manager of any sort, you can’t empower others without surrendering some of your own positional authority.

Gary Hamel, Humanocracy p. 262

Antipatterns

It is just nice words on paper. In reality teams and individuals meet mistrust and a command & control mindset.

Culture of technology

With a deep and up-to-date understanding of technologies and its mega-trends comes a source of inspiration for new products not yet demanded by the customers. Apple’s iPhone is a great example. 

Antipatterns

Chase what you competitors do in a never-ending catch-up game.

Culture of business- and customer-savvy teams

The full team, not “just” the PM, has a deep understanding of the customers and of the needs and constraints in the business. 

Antipatterns

Team has misunderstood the notion of being “autonomous” in the sense that is does not have to care about internal or external stakeholders.

Culture of skill-set and staff diversity

This is directly linked to the culture of open minds appreciating that people with different skills and background can contribute to innovative solutions.

Antipatterns

We know best!

Culture of discovery techniques

The teams have not only one but a variety of techniques helping the teams quickly to discover the best solutions to the given problems … and do it in a way protecting RT’s brand, revenue, customers and colleagues.

Antipatterns

Make everything a project.

Wrap-up

Now having understood the targeted future situation – the vision- for RT, the next post will discuss the strategy for how to make the vision come alive.

Spoiler alert: start small.

Stay tuned!

Posted on

Renewable Tech – the journey towards a strong Product company (part 1)

Renewable Tech part one

This post is the first in a series of posts discussing the hypothetical company, Renewable Tech [RT]’s journey towards the vision of becoming a strong and undisputed market-leading Product company within renewables technology, from primarily being a provider of customer-specific solutions.

Becoming a product company

Context

This first post will primarily be used to set the scene e.g., describing the context within which RT operates.

RT and its customers

RT is a successful B-t-B company providing customer specific solutions to OEMs and operators in the Renewable Energy industry. One of the reasons behind RT’s undisputed success has been its strong and focused market strategy. RT knows that you cannot be successful unless you focus with active selection and equally important active decision on what not to target. Shoot at everything and you’ll end-up not hitting much. Focus within context is everything.

RT's processes supporting development of the customer-specific solutions

The current process framework governing the development and delivery of customer-specific solutions is optimized for predictability as illustrated in quadrant C – home for the classic project (find more on A-B-C-D here):

Optimization focus

Over time the process model has become more and more prescriptive with e.g., a lot of check-lists and heavy governance. In addition, a large segment of RT’s OEM customers have formed a consortium with the purpose of standardizing the interface between the OEMs and its solution suppliers. This has added even more prescriptive processes to the model. 

RT’s ability to operate in C, staying within the boundaries of the “project iron triangle”, is undisputed. In fact, it has an ISO 9001:2015 certification on its process consistency.

RT's management and strategy

RT’s strategy shifting focus to becoming a product company includes M&As and significant investments in innovation competences and capacity. In addition, RT is having a network of partners, including universities. 

With a solid financial foundation and a long-term thinking owner group, RT has the perfect conditions to do the right things (in contrast having to please a short-term thinking private equity fund).

RT's products

RT’s products are (and especially will be) an innovative and multidisciplinary mix of electronics (high- and low power), hardware, mechanics and software (embedded, application, app, Machine Learning ..) with some services hosted in the Cloud. If not before, with the new vision becoming a strong and market-leading product company, RT cements that technology is the product.

RT has a global footprint with production facilities, adapting an increasing amount of “Industry 4.0” elements. As will become evident in coming posts, the implementation in production of innovated products is equally important as the product innovation itself. Elon Musk’s Tesla, or SpaceX for that matter, is a perfect example of this:

Prototypes are easy, production is hard.

Elon Musk @Twitter May 3rd 2021

In fact, Musk took the credit away from the company’s (ed.: Tesla) range of electric vehicles in response to a tweet by investment firm Ark Invest, January 2021:

The factory is the product.

Elon Musk @Twitter January 2nd 2021

Companies with purely digital products do not have this added complexity. Using e.g., the latest advances in Cloud Serverless, its DevOps teams can minimize efforts spent on Operations.

RT's competitors and how to stay competitive

The market for renewable tech is big – very big – attracting global competition on the full spectrum from the niche startups to global heavy-weights. RT knows that the core differencing power is found in sustainable innovation. To quote the globally known Danish water-tech company, Grundfos, and their 2025 strategy (last page):

We INNOVATE to DIFFERENTIATE. Differentiation is our main source of competitiveness.

Grundfos 2025 strategy

One of RT’s challenges is thus to grow strength in quadrant A (see the illustration above – the home for product innovation) being fundamentally different in mindset and approach compared to quadrant C. In A focus is on creativity and hard thinking – not on C‘s process compliance.

I don’t believe in process. In fact, when I interview a potential employee and he or she says that ‘it’s all about the process,’ I see that as a bad sign. The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative.

Elon Musk

This will be a key area to discuss in the coming posts.

Sources of inspiration in this series of posts

Combined with my own practical experience and theoretical toolbox, this series of posts will seek guidance from the North Star provided by e.g., Marty Cagan, Teresa Torres, Gary Hamel, Matthew Skelton, John Doeer, Jeff Patton and others. This should give you some idea on the direction and mindset applied.

I’ll be assuming that RT’s employees already have a solid insight in and practical experience with the Scrum / Kanban frameworks (if not – get trained), and with the good old virtues of project management thus not spending much time on those basics.

I’ll also be assuming that solid engineering practices are in place in all technology areas. 

The vision to become a strong market-leading high-tech Product company

RT has spent a considerable amount of time and effort collecting insights, testing hypothesis and formulating a compelling, motivating and ambitious vision. RT’s executive management is highly inspired by Jeff Bezos.

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.Jeff Bezos

Stay tuned for the next post in this series discussing the vision.

Posted on

101 Artificial Intelligence, Machine Learning, Deep Learning and Data Science

Artificial Intelligence

If you are new to AI and Data Science and need quickly to get your head wrapped around the basic terms, this post is for you. Are you already experienced in the field, you might want not to spend your time with this post.

With the curtesy of Shehroz Aslam I became aware of a the Coursera course by Andrew Ng explaining the world of AI and Data Science in an easy-to-grasp fashion. 

The aim here is to cherry-pick from Andrew Ng’s great insights.

Understanding the basic terms and their relation

The Sentinels in the Matrix or robots in The Terminator are stereotype and malign examples of Artificial General Intelligence (AGI). Only time will know if or when AGI could become a reality. In this post we’ll maintain contact with reality and “only” focus on Artificial Narrow Intelligence (ANI).

The top-level break-down of Artificial Intelligence as illustrated by Andrew Ng

AI break-down

It is decades, maybe hundreds or even thousand of years away before AGI can do what humans do Andrew Ng

Andrew Ng lists some well-known ANI applications e.g., self-driving car, smart speaker, web search, quality control in production etc.

Tools used to bring intelligence to computers

The universe of AI is rapidly branching. Here we’ll stick to the main branch as laid-out  by Andrew Ng.

Andrew Ng provides some examples of open-source Machine Learning frameworks:

AI tools
Posted on

Building a cathedral – mercenaries or missionaries

Mercenaries or missionaries

Two craftsmen are working on a cathedral, each having their own toolbox. During the coffee break they have a heated debate on which toolbox is best. Why not discuss the bigger issue – the cathedral? Because the toolbox is easy to understand.

On LinkedIn and other media you’ll find the same type of toolbox/framework discussion over and over again. 

What would be much more interesting is to learn about the cathedral and the real challenges. Only when understanding the strategic context does it become interesting to learn about the thinking and rationale behind the choice and implementation of toolboxes/frameworks. 

This post will elaborate on the question of how to manage today’s complexity in a sustainable way – and yes – missionaries are part of the answer.

The toolbox/framework discussion will continue because it is easy. The day after tomorrow a new Silver Bullet will see the light of day: “The Half-Triple” toolbox/framework. You better start a Transformation program as of now – your competitors read about it yesterday in a magazine on a domestic flight.

Contract signingThis is an easy sell to the busy CEO already struggling with the last major and far from finished transformation. Just sign on the dotted line and we’ll make miracles happen in your organization … this time.

For those of you old enough to remember it, back in the past millennium we had an industry selling the wet dream of nearly automated software development. It was called CASE – Computer Aided Software Engineering. The same thing: a promise to have complex problems, or wicked problems if you will, go away – just sign on the dotted line. 

In a hurry? Jump directly to the wrap-up.

Complexity is here to stay

What has made FAANG (Facebook, Amazon, Apple, Netflix, and Google) … and Tesla, and SpaceX successful is not their choice of toolbox/framework. In fact you’ll not hear much talk about e.g., “Agile” in these companies. Variations of Agile toolboxes / frameworks is part of their basic toolbox, just like being competent writing code in C#. As described earlier, they are focused on their Product Culture which is much more than some toolbox/framework. You’ll find (highly competent) missionaries here working for a bigger cause – not just mercenaries being told what to do.

It does not make sense to hire smart people and tell them what to do. We hire smart people to tell us what to do.

Steve Jobs

Rather than fixating on some tools/frameworks, I recommend reflecting on the question

 “how can we build a company culture filled with missionaries?” 

Your answer to that question is what really addresses complexity in your organization.

From mercenaries to missionaries

PuzzleThis is a very big and hard topic highly dependent on your specific business context. What differentiates a mercenary from a missionary? What is the difference between bureaucracy and humanocracy? What are the traits of a “Product Culture”? How can we obtain sustainable changes?

Here I’ll limit the input to recommending  and commenting on some worthy-to-read books, proving bricks to the missionary puzzle.

Humanocracy

HumanocracyGary Hamel’s book Humanocracy takes the bureaucracy under the microscope contrasting it to what he describes as humanocracy. Here are some touch-downs from his book:

    • [page 8] Hamel contradicts the statement “The lack of adaptability is due to the human nature – people are against change” with “We as humans are change addics with an insatiable appetite for the new. Unlike human beings, organizations are pretty much crap at change”.
    • [page 16] on what drives engagement: “Purpose, autonomy, collegiality, and the opportunity to grow”.
    • [page 20] on bureaucracy vs humanocracy: “In a bureaucracy human beings are instruments, employed by an organization to create products and services. In a humanocracy, the organization is the instrument – it’s the vehicle human beings use to better their lives and the lives of those they serve”
    • [page 262] on leadership: “Leadership is not defined by the exercise of power but by the capacity to increase the sense of power among those led. If you’re a manager of any sort, you can’t empower others without surrendering some of your own positional authority”
    • [page 265] on hacking management: “Ultimately you have to change the core processes by which your company is run – planning, resource allocation, project management, product development, performance assessment, promotion, compensation, hiring, training, and all the rest. Each of these processes must be rebuilt atop the principles of humanocracy”
    • [page 289] on rethinking leadership: “Competence in the Leadership tasks that really matter – spotting opportunities, energizing colleagues, challenging vested interests, reimagining business models, and nurturing others – doesn’t correlate with hierarchy and receives little or no attention in most leadership programs”
    • [page 290] on rethinking change: “The traditional change model is wholly inadequate. Most change programs still confirm to Kurt Lewin’s seventy-year-old, three-stage change model, unfreeze – change – freeze”
    • [page 292] on rethinking change: “Senior management must embrace the complexity of systemic change while resisting the urge to fabricate exhaustive and highly prescriptive change programs”

Should you need an eye-opener, try Hamel’s Bureaucracy Mass Index tool with ten questions across these seven categories of bureaucratic drag:

    • Waste – number of organizational layers and time spent on low-value bureaucratic tasks
    • Friction – bureaucratic impediments to speedy decision making
    • Insularity – percentage of time devoted to internal versus external issues
    • Autocracy – limits to frontline autonomy
    • Conformity – likelihood that unconventional ideas are greeted with skepticism or hostility
    • Timidity – constraints on experimentation and risk taking
    • Politicking – the prevalence of political behaviors and the role they play in determining personal advancemant

INSIPRED

INSPIREDIn INSPIRED, Marty Cagen provides a unique insight into how the best Product Teams have become the best. (Also) this book is filled with insights making it hard to select passages, but I’ll give it a try:

    • [page 23] on getting beyond Lean and Agile: “People are always searching for a silver bullet to create products, and there is always a willing industry – ready to and willing to serve with books, coaching, training, and consulting. But there is no silver bullet. As I write this, it’s in vogue to criticize both Lean and Agile.”
    • [page 34] on strong product teams: “With reference to John Doerr, we need teams of missionaries, not teams of mercenaries. Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and committed to solving problems for their customers.”
    • [page 39] on strong product teams: “If your company is not yet set up around dedicated product teams, this is probably the most important thing for you to fix. Everything else depends on it.”
    • [page 40] on strong product teams: “I have found over the years that while techniques change fairly constantly, the underlying principles endure”
    • [page 163] on product discovery: “If you want to discover great products, it really is essential that you get your ideas in front of real users and customers early and often. If you want to deliver great products, you want to use the best practices for engineering and try not to override the engineers’ concerns.”
    • [page 178] on discovery framing: “Fall in love with the problem, not the solution.”
    • [page 286] on transformation techniques: “People are people. As a very explicit example, moving from a mercenary-style, product roadmap-driven, output-focused teams, to truly empowered, accountable product teams that are measured by business results, represents a major cultural shift and a substantial handoff of power and control from management to the individuals in the teams.”
    • [page 289] on transformation techniques: “Many problems arise because the vast majority of these Agile coaches don’t have experience with tech-product companies, so their experience is limited to delivery. Therefore they would more accurately be considered Agile delivery coaches. They understand the engineering and release side of things, but not the discovery side of things.”

Overarching it all is what Marty Cagan describes as Product Culture. Culture is hard to put into boxes, but you’ll recognise a strong culture when you see it. Here [page 324] are some of Marty Cagan’s “Product Culture” elements:

    • Culture of experimentation
    • Culture of open minds
    • Culture of empowerment
    • Culture of technology
    • Culture of business- and customer-savvy teams
    • Culture of skill-set and staff diversity
    • Culture of discovery techniques

EMPOWERED

EMPOWERED by Marty Cagan takes the more strategic view on the Product Company seen from the Product Leader perspective. As was the case with INSPIRED, I’ll try my best to select passages:

    • [page 9] on empowered product teams: “In strong product companies, teams are given problems to solve, rather that features to build, and most importantly, they are empowered to solve these problems in the best way they see fit. And they are then held accountable for the results.”
    • [page 21] on product leadership: “Probably the most important, yet most often overlooked, element to capable management is coaching.”

Coaching is no longer a specialty; you cannot be a good manager without being a good coach.

Bill Campbell

    • [page 188] on product vision: “An inspiring and compelling product vision serves so many critical purposes that it is hard to think of a more important or higher-leveraged product artifact.”
    • [page 191] on product vision: “The product vision done well, serves as the North Star for the product organization. The product vision provides purpose for all the product teams, no matter where they are in the organization, or on what piece of the larger product they’re working.”
    • [page 243] on product strategy: “The product strategy helps us decide what problems to solve, product discovery helps us figure out the tactics that can actually solve the problems, and product delivery builds that solution so we can bring it to market.”
    • [page 375] on transformation: “Great teams are made up of ordinary people who are inspired and empowered.”

There is and there will never be a cookbook prescribing how successfully to transform an organization into the strong product company. On a very high abstraction level, Cagan suggest [page 378] three major steps, preferably done in sequence:

    • Have strong product leaders in place
    • Give these strong product leaders the ability to recruit and develop the staff required for empowered product teams
    • For the product teams that are ready to operate in the empowered product team model, you’ll need to redefine the relationship to the business

Wrap-up

We are humans for good and for bad. If we design organizations in a way nurturing the good, not amplifying the bad, then we’re on the right track. The missionary mindset encapsulates that idea.

The bad news is that it is hard to nurture an organization with missionaries. The bad news is also that you cannot buy an easy fix by having your employees trained in e.g., various toolboxes/frameworks..

Inflight magazineThe good news is that it is possible and that you’ll gain a sharp competitive edge in terms of market and in terms of attracting the best-of-the-best employees.

The quest for an organization of missionaries is not comparable with the “you need to ride this wave, consultancy fix”. It is a fundamental and durable reprogramming of the organizations DNA. Marty Cagen describes it as “Product Culture”.

Though very different in approach and context, the authors Hamel and Cagan have the same core message (formulated differently): 

Design your organization for people and teams to thrive in a culture of missionaries. 

The (hard) question is now: how long will you wait before aiming for a missionary-driven organization (your competitor might have read about it in an inflight magazine during the latest domestic flight)?

Posted on

Output vs Outcome

Output vs Outcome

I’ve made a quick (non-scientific) survey of Danish blog-posts related to Agile and job-postings from high-tech companies HQ’ed in Denmark, searching for Output vs Outcome. Focus is still predominantly on Project and Agile teams providing efficient and continuous delivery of Output; not Outcome

Please let me quote Jeff Patton:

The biggest missing value statement in the Agile Manifesto is:

Successful outcomes over efficient deliveryJeff Patton

Why this obsession on Output (delivery) over Outcome?

I see two primary reasons for organizations measuring Team success on Output and not on Outcome.

The business model is based on delivering Output to others

Being a Service / Solution provider (internally or externally) you’re awarded for your ability to deliver Output to your stakeholders according to agreements (read: the Project Triangle). This is where you’ll find Agile / Project teams with mercenaries being told what to build and deliver. These teams can of course not be held accountable for the Outcome of their deliverables for the simple reason that the teams were told what solution to build.

The obsession to deliver Output in the most effective and efficient way is only natural here. The success criteria is not the ability to Discover/ Innovate the best solution to a (hard) business / customer problem. It is to implement and deliver the solution / features given to the teams like a Lean Machine.

A Project mindset in a Product company

As described earlier, the best and most successful high-tech Product companies have developed a strong Outcome-focused Product Culture around Product Teams – with a missionary mindset.

Getting to this is definitely hard – especially if your organization has a traditional Project Mindset with internal stakeholders pushing project / feature roadmaps when developing new products. Your natural focus will be on Output.

Conclusion

Having focus and measuring success on Output is not “wrong” or “bad”. Your business model might be based exactly on the ability to deliver Output making it perfectly valid to optimize the “delivery machine” using e.g., the latest and greatest in Agile frameworks.

Do you happen to have a high-tech Product company with a strong tradition for Projects (measured on Output), you might want to learn from the best when it comes to Innovation: Develop a strong Product Culture with Product Teams focused on and accountable for Outcome. The stronger your “Output-focused” roots are, the tougher it is to make such a transition.

Posted on

The right tool for the right problem

The right tool for the right job

We all know it: selecting the right tool for the right problem renders the best quality with the shortest time and least cost spent. Of course you need also to have the competence and experience using that given tool.

In a hurry? Jump directly to the Conclusion.

Product company and Solution Provider - market and optimization focus

Inspired by LeadingAgile we’ll view the optimization matrix below from the viewpoint of the Product Company and of the Solution Project Provider. Note that the “Solution Provider” need not be an external party. An internal “Service Provider” servicing the business is very common in organizations with a poorly developed Product Culture. See e.g., The Service Provider Mindset and why you do not want it.

Below we’ll assume 

    • the Solution Project Provider to be an external party with a simple business model: have the portfolio of Solution Projects in average provide a contribution ratio above xx%, assuming no cash-flow after a closed project, and have the projects run under a tight governance model
    • the Product Company to be a major player in the market for advanced water technology products and solutions
Optimization focus

A: Optimize for adaptability in an emergent market - home for Product Innovation

Product company

The right tool for the job: A solid Product Culture upon which a network of Product Teams conduct Product Innovation. The Product Teams are tasked with (hard) business/customer problems for which they are empowered to Discover the best solutions but held accountable for the business Outcome.

The wrong tool for the job: Trying to drive innovation with a predictability Output mindset using a classic Project approach. It should be obvious that the classic business-case driven project with success measured on the project triangle does not apply here. Despite this you’ll often hear organizations trying to do exactly that using “Product Development projects” governed by the organizations “project model”. 

Solution provider

The Solution Project Provider is not accountable for the Outcome in the water technology market. Its focus is ensuring a predictable business on each Solution Project provided to the Product company; that is focus on predictable Output governed by the classic project triangle.

It is very unlikely that the Product company will outsource the innovation of a full product to the Solution Provider, for several reasons e.g.,

    • the Solution Providers business model is at odds with the Product Culture in the Product company
    • we’re talking a highly strategic area

The Product company might, during Product Discovery, have identified a non-strategic solution area. In the quest to focus its own critical capacity, the Product company might decide to carve-out and outsource a classic Solution Project.

B: Trying to achieve predictability in an emergent market

Product company

If you find yourself in this quadrant, the recommendation is to review your business vision and strategy.

If the product area in question is outside your strategic focus, you might want to engage a proven Solution Project Provider thus prioritizing your own critical capacity for strategic innovation.

Solution provider

The Solution Project Provider could easily be invited to quote on this type of project and tempted to quote on it. The stakes are high here and so are the potential wins. If you are a mature, focused and competent Solution Provider, this could be an interesting quadrant for you.

High stakes

Do not try entering this game, if you do not have a sharply defined marked focus and understanding or, if you are not among the best. 

C: A predictable business in a mature market - home for the classic Project

Product company

Applying a classic Project is also highly relevant for the high-tech Product company; just not for Product Innovation e.g.,

    • Major changes to the production setup requiring a high degree of predictability; e.g., setting-up a new production site
    • Delivery of well-defined customer solutions
    • M&A projects
    • …

The good old virtues of solid Project Management are here to stay … for some problems.

Solution provider

This is the bread & butter quadrant matching the business model for the Solution Project Provider: Deliver Output according to clearly agreed specifications.

Bread and butter for the Solution Provider

D: Optimize for adaptability in a mature market - home for incremental changes

Product company

The situation for our high-tech water company is e.g., a stable Product/Market fit with customers requesting tailored end-to-end solutions. 

For the Product company to meet these market requests, the ability to make smaller, fast but highly controlled changes to the product / production modularization is key. 

The Product Team(s) will thus primarily operate in an agile delivery mode. See also Dual-track Agile.

Solution provider

Unless the Product company faces larger, clearly specified and encapsulated changes suited for outsourcing, the Solution Project Provider does not have a viable business platform here.

The "Agile Project"

The “Agile Project” is also by some named a “hybrid model”. Is this the magic potion for high-tech Product companies?

Examples are

These “hybrids” all try to position themselves as the-best-of-both-worlds models. They are all surprisingly bloated and prescriptive with their own developed terms, templates, processes, practices etc. Not much “Agile” really. You’ll find a whole ecosystem of institutions basing their business on (re-)certification, education, coaching..

In contrast, the Best Product Companies have a Minimum Viable Bureaucracy approach with as little process prescription as possible. Instead these best-in-class companies have a rich pich&use buffet with processes, tools, golden path etc. supporting their network of Product Teams and their overarching Product Culture.

Just to prove the point that you do not need big and bloated project models as a consequence of your size and success: Amazon is one of the most clean-cut examples of a successful high-tech Product company having maintained an extreme degree of business agility throughout its network of Product Teams despite its exponential growth.

The physical world and "Agile"

A relevant concern is often heard when the product is not 100% software-based: how can we ensure “continuous delivery” on the physical parts of our product? 

You are of course limited by physical constraints not present in pure software, but what you can and should do when innovating a multidisciplinary product with physical dimensions is to

    • use simulation models / digital twins
    • use evaluation kits
    • move relevant parts of hardware to software using e.g., Field Programmable Gate Arrays (FPGAs)
    • maintain the fast and disciplined experiment / learn Product Culture as in pure software products
    • learn from the software guys: encapsulate complexity behind stable APIs / interfaces
    • test integration interfaces again and again – experience clearly shows that problems show-up here
    • use the 3D printing technologies that has become both highly advanced and mature

The short answer is thus: it makes perfect sense also to apply Dual-track Agile (Product Discovery and Product Delivery) to products not purely digital.

Conclusion

The Product company has its focus on Outcome as the result of innovating and bringing the right products to the market. Contrast this to the business model of the Solution Project Provider being focused on delivering Output.

The product lifecycle in the Product company is owned by its network of Product Teams with a shared and strong Product Culture and mindset contrasting the classic Project mindset.

Mindset, output and outcome

Even for the Product company some problems are best handled using a Project approach … the right tool for the right problem.

Posted on

The gap between the majority and the best high-tech Product companies

Gap between the rest and the best

The aim with this post is through a scenario to illustrate the gap between the majority and the best when it comes to innovation of high-tech Products.

Setting the scene

Team Beetle and Team Mc Laren are both Product companies doing their own high-tech BtB Product innovation and production in the Renewable Energy market.

As will be evident below, the two companies are very different in many aspects.

Team Beetle - among the majority

For the last several years, Team Beetle has achieved significant success as a Solution Provider to e.g., major OEMs through a focused and strong business strategy. Only a small fraction of Team Beetle’s innovation capacity has been spent on its own product portfolio.

Team Beetle has lately revised its overall business vision and strategy moving its focus to Product innovation with the ambition to become among the best high-tech Product companies in its field founded on a strong Product Culture.

Though some initiatives have been taken on e.g., DevOps teams, the organizational structure and mindset is classic far from having the aspired Product Culture. The spine-reaction in Team Beetle when faced with a challenge is driven by the modus operandi in the Solution Provider part of the business: a Project and its substantial bureaucracy.

Slow

Team Mc Laren - among the best

Fast

Team Mc Laren was born out of the start-up environment with a strong focus on Product Management and Product Teams. Despite its success and exponential growth, Team Mc Laren has managed to maintain its original start-up traits being extremely customer-focused and having a Minimum Viable Bureaucracy governing its high-tech Product innovation.

The developers are highly skilled developing the solution, once identified during Discovery, meeting the Brands quality expectations.

You’ll not hear Team Mc Laren talk about having business agility, using specific Agile Frameworks or having “Agile Coaches”. They care about their Product Culture.

An internal stakeholder has an input for business improvement on a Product

We’re here assuming a product with a successful Product/Market fit. The Strategic Sourcing function (sourcing production material across the full product portfolio) has identified a new core component when used, will reduce the total production cost by estimated 20+% of the given Product. The caveat is that a radical product design change is needed which in turn demands significant changes in the Advanced Manufacturing configuration.

Team Beetle

The first obstacle met by Strategic Sourcing is finding the right person to talk to. They end-up talking to the VP of Engineering, who happens to be a very busy man. The message from him is 

    • My department is already fully loaded the next 18 month
    • You’ll need to use formula xyz for a change request, and have that change request presented for the central Change Control Board; they meet next time in three weeks
    • The PMO is low on Project Managers; you might want also to have a talk with the Head of PMO. He’ll have to adjust the Project Portfolio and move people around

It is very clear where Team Beetle has its focus: On Output, which is no surprise. The ability with a high degree of predictability to deliver Output within the traditional Project Triangle has been the primary measure of success in the Solution Provider business model.

Project Triangle

Team Beetle has big road maps stating which features (Output) must be developed and delivered when. 

Conclusion

This is what killed by bureaucracy and Output-based Project Thinking looks like. Instead of acting on this strong input, Team Beetle missed the window of opportunity leaving it open for the competitors to exploit.

Not only was the Product opportunity missed; the guys from Strategic Sourcing was left disillusioned and will probably not bother bringing this type of opportunity forward again.

Team Beetle needs a fundamental re-programming of, what success looks like. Being a Solution Provider with a Service Provider Mindset, of course calls for the Output mindset.

In contrast, the Product company will of course need to focus on Outcome. 

Team Mc Laren

Strategic Sourcing knows exactly who to address: a specific Product Manager or the Head of Product (the CPO – Chief Product Officer). It is hardwired in the Product Culture DNA that a Product Manager has a deep knowledge of your business including an alignment with his stakeholders.

The Product Manager is excited to learn about this opportunity to further improve the Outcome generated by his product (yes – he feels a strong ownership). He has always a high awareness of the four core Product risks (ref. INSPIRED page 165)

    • Value risk – will the customer buy this, or chose to use it?
    • Usability risk – can the customer figure out how to use it?
    • Feasibility risk – can we build it?
    • Business viability risk – does it work for our business?

Based on the input from Strategic Sourcing, the Product Manager concludes that he’ll need the engineers in the Product Team to design and run a quick set of feasibility experiments. Because the Product Manager is driven by a strong Product Culture, he want decisions to be made on facts being conclusions from the experiments.

Team Mc Laren knows where value is created: in the Product Teams. The whole Leadership structure and mindset is optimized for exactly providing the best conditions for the network of Product Teams to thrive.

Foundation for business agility

Conclusion

The engineers saw no major feasibility risks, and the Product Manager agreed with the Product Team to update the existing OKRs and suggest new ones to the Head of Product.

If the change of the core component had influenced the Product Strategy and maybe even the Product Vision, then the Product Manager would have negotiated changes with the Head of Product and Head of Technology.

Team Mc Laren demonstrates what business agility is about.

Wrap-up

Getting and maintaining (despite rapid growth) a strong Product Culture is hard. If your roots are founded in a classic Output-based Project Mindset, your challenge is even harder. Not only do you need to learn fundamentally new ways of working; you also have to unlearn much of what before has been considered best practice.

The good news is that the sooner you (being a company aspiring to become a successful high-tech Product company) get started, the better are your chances to get ahead of competition. 

Posted on

The Service Provider Mindset and why you might not want it

Service provider mindset

Most people with an “agile mindset” will agree that we’re here to serve the customer in the Product company. By customer we here mean the real customer, purchasing and using the Products we’ve developed. Sounds obvious – what else?

In a hurry? Jump directly to the conclusion.

The Service Provider Mindset

In many Product companies you’ll still find the blurry notion of “the internal customer” being e.g., Sales, Marketing, Functional managers, Executives, (the old school) Product Management etc. This results in a Service Provider Mindset where the development teams service the business; not the real customer. In addition you make your teams focus on Output and not on the resulting Outcome.

The Product Owner (Scrum role) will essentially focus on a Product Backlog as a compromise between these “internal customers”. The development teams end-up as mercenaries being told what solutions to implement which is why they cannot be held accountable for the Outcome. This accountability is as blurry as the “internal customer”.

Note: As Marty Cagan points-out again and again, the Product Owner is far less than the (modern) Product manager (see also the CSPO Pathology).

This summer Jeff Patton wrote the article The Mindset That Kills Product Thinking elaborating on why you do not want a Service Provider Mindset in your Product company, and where this mindset came from. Should you have the time, you might also want to hear Jeff talk in the video below from last year. Jeff’s focus is on digital products, but most of his insights apply in general.

Here is an attempt to extract some of the essence from Jeff

The Agile Manifesto from 2001 was written from a Service Provider mindset!

The 1. principle in the Manifesto states:

Our highest priority is to satisfy the customer through early and continuously delivery of valuable software

The focus is clearly on Output – deliver software – and not on Outcome.

Jeff suggests that the biggest missing value statement in the Agile Manifesto is:

Successful outcomes over efficient delivery

How to spot the Service Provider Mindset

Symptoms:

You and your team are evaluated based on your velocity of work, and not the outcomes your product results in

Someone outside your team decides what you’ll build & you rely on their approval before considering your work done

Your biggest risks are almost always time, cost and scope & risks are rarely about whether customers really want, can and will use your product

You and your team don’t know the real outcome of your work

Given you happen find yourself caught in a Service Provider Mindset, Jeff has some suggestions for how to get free from its gravitational field:

Identify your product(s)

Evaluate the success of your product(s) as it is today

Really get to know your customers and users

Identify opportunities for continous product improvement

Talk about expected outcomes before you build, make or change anything

Reflect on the outcome of everything you deliver

Conclusion

If you happen to be in a high-tech Product company, you have to do what the best do: focus on your real customer and focus on Outcome. You might currently be caught by a Service Provider Mindset in your company. In that case you need to re-calibrate the understanding of your customer.

What probably most people are not aware of, is that the Agile Manifesto was carved-out from a Service Provider Mindset. The Service Providers see their client as their customer which in turn is accountable for the real customer and Outcome. Put in other words: adapting one of the Agile Frameworks does not automatically make you focus on Outcome – actually the opposite!

Not only is getting your people to master Agile Frameworks only a fraction of what it takes to become a strong Product company. You need to make sure to have your “Agile coaches” understand, who your real customers are … and it is not the internal stakeholders.

Posted on

We need business agility in our high-tech Product company

Agility

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:

  • The capacity-management (read: bureaucracy) grows exponentially as the number of projects grow
  • The friction grows due to internal politics between the functional silo managers each with their local KPIs and functional strategies
  • The team efficiency is highly impeded due to the fact alone that it is an ad-hoc team. What in addition often happens is that Project team-members are flying in and out of the project, because the silo-managers need them to help extinguish fires elsewhere
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:

CTO

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.

CPO

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

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” :

Porpose

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.

Empowerment

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

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

Conclusion

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.

Some of Claus’ inspirational sources

Some of Claus' inspirational sources

Some of Claus' inspirational sources

Claus is driven by a thirst for new insights and continuous improvement being visible on his bookshelves and time spent on the wealth of on-line  knowledge.

You might also want to visit the ProjektDK BLOG.

Picks from Claus' bookshelves

Karsten Dahl Vandrup and James Hindsgavl Brink – NIS2 Strategisk, taktisk, operationelt

Christian Vandsø Andersen – Magic @ Work: Leadership, innovation, and personal mastery in unpredictable times. Inner secrets from being both a magician and vice president at the LEGO group

Wonderful digital leadership

Christian Vandsø Andersen – Wonderful Digital Leadership: A different look at time, innovation and leadership in a digital world

The Art of Action

Stephen Bungay – The Art of Action: How Leaders Close the Gaps between Plans, Actions, and Results

The hard thing about hard things

Ben Horowitz – The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers

Accelerate

Nicole Forsgren PhD,  Jez Humble, Gene Kim – Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

Steve Pereira, Andrew Davis – Flow Engineering: From Value Stream Mapping to Effective Action

Christopher Cowell, Nicholas Lotz, Chris Timberlake  – Automating DevOps with GitLab CI/CD Pipelines: Build efficient CI/CD pipelines to verify, secure, and deploy your code using real-life examples

Modern Software Engineering

Dave Farley – Modern Software Engineering: Doing What Works to Build Better Software Faster

Dave Farley – Continuous Delivery Pipelines: How To Build Software Faster

Continous Delivery

Jez Humble (Author), David Farley (Author) – Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

Bent Flyvbjerg How Big Things Get Done – The Surprising Factors Behind Every Successful Project, from Home Renovations to Space Exploration

Reed Hastings No Rules Rules: Netflix and the Culture of Reinvention

When Agile gets Physical

Katherine Radeka  & Kathy Iberle When Agile Gets Physical: How to Use Agile Principles to Accelerate Hardware Development

Katherine Radeka The Shortest Distance Between You and Your New Product

BUILD

Tony Fadell Build: An Unorthodox Guide to Making Things Worth Making

Transformed

Marty Cagan – Transformed: Moving to the Product Operating Model

Loved

Martina Lauchengco LOVED: How to rethink marketing for tech products

Marty Cagan EMPOWERED: Ordinary People, Extraordinary Products

INSPIRED

Marty Cagan INSPIRED: How to Create Tech Products Customers Love 

Teresa Torres Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value

Product Discovery

Martin Christensen and Marcus Castenfors Product Discovery: A no-nonsense guide to building effective products and services

Value Proposition Design

Alex Osterwalder Value Proposition Design: How to create products and services customers want

Testing Business Ideas

David J. Bland Testing Business Ideas: A Field Guide for Rapid Experimentation

High-impact tools for teams

Stefano Mastrogiacomo High-Impact Tools for Teams

The Invincible Company

Alex Osterwalder The Invincible Company

The Lean Product Playbook

Dan Olsen The Lean Product Playbook: How to innovate with minimum viable products and rapid customer feedback

Team Toplogies

Matthew Skelton & Manuel Pais Team Topologies: Organizing Business and Technology Teams for Fast Flow.

Effective Project Management

Robert K. Wysocki Effective Project Management: Traditional, Agile, Extreme, Hybrid

Eric Ries The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.

Dare

Eric De Groot & Matthijs Rosman DARE: The mindset for successful innovators in the digital age.

Steven Levy IN THE PLEX: How Google thinks, works, and shapes our lives

John Doerr Measure What Matters. OKRs: The Simple Idea that Drives 10x Growth.

Thinking fast and slow

Daniel Kahneman Thinking, Fast and Slow

Humanocracy

Gary Hamel Humanocracy:  Creating Organizations as Amazing as the People Inside Them.

[In Danish] Morten Münster Jytte fra Marketing er desværre gået for i dag: How to use behavioral design to create changes in the real world.

Jytte vender tilbage

[In Danish] Morten Münster Jytte vender tilbage: The unmodern guide to create changes against all odds.

Daniel Akenine Fundamentals of IT Architecture.

How innovation works

Matt Ridley How innovation works: And Why It Flourishes in Freedom.

Christina Wodtke Radical Focus: Achieving your most important goals with Objectives and Key Results.

Note: A second edition is also available.

Radical Focus 2nd edition

Christina Wodtke Radical Focus, second edition

Crossing the chasm

Geoffrey More Crossing the Chasm, 3rd Edition: Marketing and Selling Disruptive Products to Mainstream Customers

Product Operations

Melissa Perri Product Operations – How successful companies build better products at scale

.

Build Trap

Melissa Perri Escaping the Build Trap: How Effective Product Management Creates Real Value

Sprint

Jake Knapp Sprint – How to Solve Big Problems and Test New Ideas in Just Five Days

User Story Mapping

Jeff Patton User Story Mapping: Discover the Whole Story, Build the Right Product

Essential Scrum

Kenneth S. Rubin Essential Scrum: A practical guide to the most popular agile process

Lean Software Development

Mary and Tom Poppendieck Implementing Lean Software Development: From Concept To Cach

Lean Software - an agile toolkit

Mary and Tom Poppendieck Lean Software Development: An Agile Toolkit

Agile Estimating and Planning

Mike Cohn Agile Estimating and Planning

Coaching Agile Teams

Lyssa Adkins Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition

David J. Anderson Kanban: Successful Evolutionary Change for Your Technology Business

Scrumban

Corey Ladas Scrumban – Essays on Kanban Systems for Lean Software Development

The Scrumban [R]Evolution

Ajay Reddy The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban

SAFe 5 Distilled

Richard Knaster, Dean Leffingwell SAFe DISTILLED

Paolo Sammicheli Scrum for Hardware

Scrum for hardware design

David G. Ullman Scrum for Hardware Design

Making sense of Agile Project Management_200x244

Charles G Cobb  Making Sense of Agile Project Management – Balancing Control and Agility

AXELOS A blended approach combining PRINCE2 and Agile, PRINCE2 Agile gives project managers the skills and knowledge to benefit from agile delivery, whilst maintaining purposeful levels of control with PRINCE2

PRINCE2 manual

AXELOS Managing Successful Projects with PRINCE2 ©

Pseuco-work

Dennis Nørmark & Anders Fogh Jensen Pseudo-work: How we ended up being busy doing nothing

7 habits

Stephen R. Covey The 7 Habits Of Highly Effective People

Please note that Claus is in no way affiliated with the authors of these books.

Some of Claus' on-line sources of inspiration

AWS Executive Insights

Elements of Amazon’s Day 1 Culture – quote: “Amazon’s *Day 1* mentality is a culture and an operating model that puts customers at the center of everything Amazon does. Putting *Day 1″* into practice relies on maintaining a long-term focus, obsessing over customers, and bold innovation.

Contrast this to a *Day 2* mentality: as a company grows over time, it needs to adjust its approach to effectively manage the organization as it scales. The danger is that as this happens, decision making can slow down, and the company can become less agile, moving further and further away from the customer as it rotates focus towards internal challenges rather than external customer-centric innovation.”

Sustaining a Day 1 Culture – quote: “If you create a culture that pushes itself to look for new ways to delight customers every single day, in all parts of your business, it will drive you to invent on their behalf.”

Insights blog at svpg.com

Silicon valley product group (svpg) is founded by Marty Cagan, the author of the two books “EMPOWERED” and “INSPIRED” above. This blog nicely extends the books.

The CSPO Pathology – quote: “The fastest growing pathology I see, especially outside the US, is people confusing a product owner (the role on an Agile delivery team) with a product manager“

Revenge of the PMO – quote: “A couple years ago I wrote about the root causes of product failure in product companies and I identified ten key attributes of Waterfall and project-mindset. I went through and compared this list with SAFe, and literally all ten problems exist in SAFe. Indeed, I would argue that all ten problems are inherent in that process.”

Product Ops Overview – quote: “From my own interactions with companies implementing or exploring Product Ops, I have found no fewer than six distinct definitions.

So the first and most obvious question is why so many different definitions? 

My theory is that while the term emerged as a roughly parallel concept to DevOps, the original concept of DevOps refers primarily to tools and technology to empower engineers to accelerate their code into production, but I haven’t encountered anyone trying to do roughly analogous tooling for product managers (other than tool vendors of course).

I think that’s partly because there are already plenty of off-the-shelf solutions for the major tools like roadmap and OKR tools, but mainly because unlike engineering, for most things PM’s do, it’s simply not a function of the tools, so the original meaning of DevOps doesn’t really apply so well to product management.

That said, the concept of empowering product managers to do good work, much like we empower engineers, resonates very easily.”

Blog at producttalk.org

Teresa Torres run this blog, and she is the author of the book “Continuous Discovery Habits” above. Teresa is generously sharing insights in her blog.

Medium.com

You need to search a bit, and you’ll find a wealth of high-quality articles.

Steve Denning at forbes.com

Steve Denning writes primarily about Leadership Strategy. Here an example where he touches upon Agile ..

Understanding Fake Agile – quote: “There is also Agile in the sense of the various Agile brands promoted by consultants and trainers, of which there are hundreds. These are multiple variants of the same underlying idea of Agile. Yet often there is an insistence on using particular terms and specific named processes, which are defined in this way for the commercial purpose of distinguishing their offering from competing consultants and trainers.

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.”

Why Finding The Real Meaning Of Agile Is Hard – quote: “The answers you get to the question as to what *Agile* means will depend on who you ask. For many, Agile (or business agility or organizational agility, or whatever you want to call it), has come to mean a paradigm shift in management, a fundamental rethinking about how work gets done in the 21st century.

As Thomas Kuhn explained when he introduced the concept of a paradigm shift, it’s normal to encounter a great deal of confusion as to what is going on while the paradigm shift is happening. If you go around talking to random people asking what “agile” means, you will inevitably get very different answers, particularly if you are talking to people who are stuck in the old paradigm, or who are having problems implementing the new paradigm.”

Some articles on jpattonassociates.com

The Mindset That Kills Product Thinking – quote: “You can deliver what you said you would every sprint, and it may not matter if the work doesn’t result in the outcomes your organization predicted. Doing agile by the book may result in you being a great service provider, but not a successful product creator.”

Dual Track Development is not Duel Track – quote: “Development work focuses on predictability and quality.  Discovery work focuses on fast learning and validation.  Discovery and development are visualized in two tracks because it’s two kinds of work, and two kinds of thinking.”

Proudly powered by WordPress