“The FIVE DYSFUNCTIONS of a TEAM” by Patrick Lencioni – a Book review

Book review

I heard a lot about the book “The FIVE DYSFUNCTIONS of a TEAM” by Patrick Lencioni previously and found it on a list named “The Best Company Culture Books To Read“. It felt like I should give it a try.

Book structure

The book’ content wraps around a really great story around executives of a virtual tech company in the Silicon Valey finding their way from being a wild group of individuals towards a real team. There is Kathryn, a really experienced CEO coming from a totally different industry background. Jeff, the former CEO and one of the founders – now looking after business development. The CMO, Mikey, a big-shot contributor with an incredible backlog of successes in the broader tech industry. The CTO, Martin, very strong opinionated person with a clear tech-nerdy attitude and among the founding team. The CSO, JR with also a quite huge list of successes on sales side – always increased revenues quarter over quarter. The Chief of Customer Support, Carlos – one of the buddies of Mikey and a quite silent person. The CFO, Jan, who is very carefully keeping the money of the company together and the COO, Nick, who was brought to the company to fix operations.

The story is a great read and I could sympathize with various characters right from the beginning. I could also see some parallels to some of my colleagues in leadership positions. So, the fictional story is not that fictional after all. The fictive CEO Kathryn is one of the CEO’s you would want to work for – or even better – being such a role-model as a C-Level yourself.

My learnings

Patrick wraps his learnings from working with teams in this story and gives some advice at the end of the book on how to overcome the described dysfunctions. Patrick talks on his website more about the details of the model: Teamwork: The Five Dysfunctions of a Team.

Nevertheless, I’ll sum up what I learned in the next brief paragraphs.

The book is a great read. I found myself in various situations and couldn’t agree more with Patrick on his observations on leadership teams. I had the pleasure to work with outstanding CEO’s in the past, myself. One of them being Martina Bruder, the CEO at my times at FriendScout24 and the other being Florian Geuppert the CEO at gutefrage.net. It has been great to be part of the team since these teams were build around trust. I, however, worked with other leadership teams as well and know the situations described by Patrick first hand.

So, go on, build you own opinion and enjoy the story Patrick Lencioni created!

Model: The Dysfunctions of a Team by Patrick Lencioni

Dysfunction #1 – Absence of Trust

Absence of Trust among team members is primarily due to their reluctance to show vulnerability in front of the group. It is impossible to establish a basis for trust when team members are not genuinely honest with one another about their mistakes and weaknesses.

Dysfunction #2 – Fear of Conflict

Being unable to establish trust is problematic because it supports Fear of Conflict. Teams lacking in trust are unable to have frank and impassioned discussions about their positions. Instead, they use secret conversations and cautious remarks to create an environment of artificial harmony.

Dysfunction #3 – Lack of Commitment

The absence of healthy conflict is a real issue because it makes Lack of Commitment more likely. Team members rarely, if ever, buy in and commit to decisions without first raising their viewpoints during intense and open debate, even though they may pretend to agree during meetings.Returning back to their teams these team members are more likely to defend their own opinions and increase ambiguity in leadership.

Dysfunction #4 – Avoidance of Accountability

Team members try to avoid accountability as a result of this lack of commitment and buy-in. Even the most motivated and dedicated people actually hesitate to confront their teammates about actions and behaviors that seem to be unfavorable to the success of their own team unless they have agreed to a clear plan of action.

Dysfunction #5 – Inattention to Results

Inattention to Results can develop in an environment where people fail to hold one another accountable. It happens when team members prioritize their own interests over the group’s objectives, such as ego, professional advancement, or recognition, or even the demands of their own divisions.

“DECIDE & CONQUER” by David Siegel – a Book review

"DECIDE & CONQUER" by David Siegel - a book review

Book review

Coincidentally, I stumbled over the book “DECIDE & CONQUER” by David Siegel. I was attracted by the fact that the CEO of meetup.com would report on his experience as being the CEO of a very community focused organisation in a heavy change situation. David got me because he describes his bumpy ride during various transition phases (onboarding, changing vision / strategy, being sold and eventually COVID). And even better – he summarises his key learnings in 44 challenges directly reflecting from these situations – and describing en detail how he decided and why so.

The book is a great read for people who want to understand the mindset of a CEO. The CEO, who some people see as god-like in their own organisation, is a real human being – in this case David Siegel.
The whole book is easy to read, brings back many memories, and gives a lot of advice on how to make decisions in similar situations. Sometimes while reading a paragraph I had to pause and let the words sink in. David really makes you think and reflect on the situation described. If you are in a leadership position, there is a good chance that you have experienced this situation as well. Usually David gives a completely different perspective on what you would have done in similar situations. He makes you think.
The “ground rules” – David’s personal decision-making framework – are impressive. He introduces these 11 principles at the very beginning of the book. And he refers to them constantly.
The entire book is divided into 44 challenges. The challenges are essentially on a timeline that describes David’s journey to becoming CEO of meetup.com, to onboarding, and to various other situations. Some of the challenges may not be 100% relevant (have you ever had to sell your business?), but still David shows a new perspective in each situation. This different thinking, the change in perspective, is also valuable for other people in leadership positions.
I would really recommend this book to anyone who wants to expand their decision-making capabilities in different situations. It’s a great read – a mix of learning and entertainment.

The ground rules – David’s personal decision framework

Right in the beginning of his book, David names his ground rules – his personal decision framework. He uses these principles during the whole book and reminds the reader on what principle he wanted to emphasise with the just described situation / behaviour. I wanted to bring the principles up here again and give an example that describes what David had in mind with the principle. They show up during the entire book and a lot more examples are given.

Be kind

David talks about situations where he needed to lay-off people. He suggested to name the lay-off “lay-off” and adapt the whole procedure to the company culture and communicate the whole process transparently (be kind to your employees). Same applies if people don’t longer fit the company expectation – show them a kind way out of the organisation. Also, in situations where people need your help or access to your personal network – be kind and support them.

Be confident

David describes himself as a very people oriented person with a strong willingness to empower people. Therefore, the following cite is good to remember if you’re also a people focused person:

You’re not paid to manage by democracy. You’re paid to decide.

David talks about huge numbers of people leaving the company and asks what to do when this happens. Very good advice from him: Let them go and start rebuilding. In your communication in public be honest about so many leaving,

Be bold

As a leader you need to act. Especially in crisis – they present a huge opportunity for change: be confident, be bold.

If in wartime mode – be bold and enforce significant change if needed to change for the better.

Expand your options

The “expand your options” principle was a special one. I’ve never thought about actions you naturally wouldn’t do from that perspective. If looking with that angle on e.g. “smart talk at a party” or “reaching out to hundreds of contacts to get the one job” the activity becomes really meaningful. It supports you to expand your options now – or in future.

David recommends to hire team members – especially executives – via the personal network instead of limiting it to the options presented by head hunters. He really has a point here – but you better have a vivid personal network.

Also, the hint “if empowering is not working, it’s time to micromanage” made me think. My nature is to believe in the power of self-organising teams and to empower people. So is David’s. However, he has a passage in the book where he clearly identified the limitations of the empowering approach. He changed his leadership style towards commanding to expand his options.

Be long-term focused

In cases where you need to prioritise activities or projects, always try to focus on the long-term impact. Short-term decisions usually result in quick changes in direction, activism. Long-term brings in stability. Same applies for your investors. If being able to select your investors – select them according to their long-term goals.

And – back to networking – in networking there is no “bad” conversation, you never know.

Be honest

Honesty is a big influence in the book, in David being a CEO. He suggests to be honest in the relation with your investors, in negotiations and especially in employee communication. If you have to announce a lay-off, name it “lay-off” – a lay-off is a lay-off is a lay-off. Give people details about news – bad or good ones. The trust in your communication style will support them to better understand the news.

Be speedy

David gives multiple examples where speed actually really matters – especially in communication. If bad news need to be announced (e.g. the company is being sold) – do it as quickly as possible – don’t wait. Waiting means news will find its way through different channels resulting in irritation and eroding trust in you as a leader. This is especially critical if a press-announcement is on its way – you need to be faster than the press. People deserve to get the information first hand from a trusted source.

During onboarding, build your executive team as quick as possible. Don’t waste time on endless interviews looking for the perfect candidate. There will always be pros and cons with people.

Also, when announcing your new strategy for the company – better to have a half-baked strategy in place than nothing to give guidance for people. If new learnings appear, correct and adapt the vision and strategy on the way.

Be pragmatic

David also talks about dogmatic vs. pragmatic decisions. When meetup actually got at risk with the COVID pandemic he needed to be very pragmatic. He purposefully decided to break with the years-old conviction that meetup was all about in-person events.

“I needed to make a decision on my own and I needed to be pragmatic. I decided that we needed to embrace online events.”

Do what’s right for the business

That was an interesting pillar for me as well. David had multiple examples where I needed to think twice until I got the point. “Remove parts of the business if it helps saving the remainder part” or “if needed, prioritise company success over employee morale” sounded logical right from the beginning.

More interesting was “do what’s right for you, but make sure you also do what’s right for the business”. Don’t loose your personal interest – combine your personal well-being with the company well-being.

Work for your employees

When meetup experienced people leaving the organisation in masses, they started to work for the employees. They focused on positive experiences (e.g. parties on positive reasons – instead of exit parties, started community lunches, summer BBQs, …) and offered critical employees retention bonuses during this critical period. Slowly, they were able to keep critical people and turned around the ship.

With the new meetup organisation he focused on processes and systems to support the team’s decisions, enable creative approaches and reward extraordinary performance

Be surprised only about being surprised

This was the most outstanding one – and in parallel a really valuable hint. Expect all and nothing. David described many really strange situations with his investors and owners. And not being surprised by the fact but still be able to work them is really a great advice. Two examples he gave are volatile leaders where you need to expect everything, every minute and COVID.

Some aspects to keep in mind from “DECIDE & CONQUER” by David Siegel

In the beginning of his book, David describes his “ground rules” – a set of principles he’s rooting his decisions on. They support him to define his interpretation of the role of the CEO. I’ve listed the ground rules below and give some examples to make it more memorisable (at least for me).

A great example in his book is on good vs. bad leaders is this:

“A good CEO realizes that their job is to hire the right people and build an organization’s capability to make smart decisions. A bad CEO often doesn’t realize how little influence they should have on certain decisions and pushes forward, only to micromanage, disenable, and ultimately force the exit of good people, whose responsibility it should have been to make those decisions. In other words, a good CEO delegates power and works for their employees, while a bad one clings to power and makes their employees work for them.”

Another one on the importance of financing:

“When it comes to finances, one must be pragmatic, when it comes to priorities, one must be long-term focused.”

Being in interview situations yourself:

“Interviewing is dating – don’t marry your first date, and if there are red flags during the dating process, those red flags will only become stronger during marriage.”

If you left your job with a specific reason:

“Be retrospective after leaving a job. If you left for specific reasons, make sure you don’t go back to the same problematic situation”

Don’t forget if thinking about big numbers, hard conditions, and unthinkable demands:

“You are always negotiating and everything is negotiable.”

Not to forget when you start into your new role as CxO:

  • Build trust from day 0
  • Communication and transparency are king and queen
  • Don’t be afraid of bad hires – don’t expand the hiring process endlessly
  • Write the strategy of the company as a future press release
  • If you have to cut down costs – and impact the organisation – do it deep and act quickly and transparent – make cuts needed to set you up for long-term success

Hiring your executive team:

  • Hiring leaders is a CEO job
  • Hire for complementary skill sets
  • Executive Hiring with the four-step framework (page 85)
  • Never ask for references, do background research

Working with your investors or your superior:

  • Volatile leaders – swinging their opinion to A the one day, to B the other day – avoid them
  • Working with board – don’t ever trust any direction that lacks financioal accountability and solely prioritizes short-term imperatives.

Creating an impact on culture as a CxO – what you should focus on / emphasise:

10) EQ is more important than IQ

9) Transparency

8) Focus

7) Revenue

6) Performance-driven culture

5) Accountability

4) Diverse and inclusive culture

3) Analytics wins

2) Learning

1) Support and push team

If being acquired, keep your company stand-alone – don’t adopt the buyers culture

Find this book as well on my Agile Bookshelf.

OKR’s – uncovered. An Overview on Objectives & Key Results.

OKR's - uncovered

OKRs – uncovered. An Overview on Objectives & Key Results.

Objectives and Key Results are widely discussed – but what are they? Why are they so important? What do you need to keep in mind when thinking about them? How do they fit into any organization? What are prerequisites to implementing them?

This blog entry and a presentation on slideshare about OKR’s – uncovered answers some of these common questions on OKR’s.

OKR’s push us far beyond our comfort zones. They lead us to achievements on the border between abilities and dreams.

John Doerr, “Measure What Matters”

A brief history of OKR’s

The list below shows some milestones to remember when it comes to management methods.

  • 1900Taylorism – people are no human beings but merely resources. They need to be told what to do. No motivational aspects. Others control the entire work. No self-control.
  • 1950Management by Objectives (MbO) recognizes people as individuals. Motivation on an individual level starts playing a role. Birth hour of transactional leadership – principle of give and take. Achieving goals leads to earning rewards.
  • 1970OKR at Intel – CEO Andy Grove discovered a mismatch between the management model MbO and the reality of a high dynamic in the surrounding world. He started with the visualization of Key Results as milestones. It became visible how goals could be reached. People’s empowerment increases and as a result their commitment.
  • 1995OKR 2.0 at Google – Today’s OKR method is a variant of the original Intel version brought to Google through John Doerr. He got to know the method when working with Andy Grove at Intel. The decrease of cycle time and an increased level of agility made the OKR 2.0 version a perfect fit for the digital age.
    Google adopted the OKR method for a simple reason: Googler’s at these early days were data addicts. They simply liked the fact that progress towards an objective got measurable – quantify instead of quality-only.
  • NowNew Work – The OKR model supports aspects of the new work model. Each and every person strives for purpose and want their share of work being reflected in the overarching organization’s vision and purpose. OKR supports with the transparency aspect. OKR and management 3.0 fit together as well. Also the communication, transparency and streamlining aspect by OKR’s is well received by management 3.0.

Characteristics of OKR’s

Objectives and Key Results” – OKR – is a framework to set and align goals and measure achievements.
The Objective is ambitious and needs to feel uncomfortable. The Objective is clearly non-measurable and qualitative by nature. If the Objective doesn’t make you feel uncomfortable it’s too small and not a good Objective.
The Key Results clearly make the objective achievable – they draft a path to reaching the Objective. The Key Results are measurable – need to be quantifiable. They lead to grading an Objective.

OKR’s is a great communication tool. Due to the bidirectional process starting at the top and receiving feedback from the organization produces maximum transparency. Agreeing on the most important topics to work on during the next period of e.g. a quarter keeps the whole organization in sync and focused. The importance of the objectives is clear to everybody within the organization – everybody and always. Besides the focus, synchronization and transparency, OKR’s make the whole progress towards the objective measurable – quantify, not qualify.

The process around OKR’s

The process around OKR's - discussed and agreed between management and individuals in multiple steps.
The process around OKR’s – discussed and agreed between management and individuals

The overall process to establish OKR’s seems like an heavy invest of people’s time at a first glance. Staff meetings with C-Level, head-of’s with team-leads, team-leads with teams and back again are an investment. However, the whole organization gains transparency, commitment and focus. Doesn’t look like a bad trade …

The staff meetings are public where Objectives are described by management and discussed with people. The Objectives dribble down the organization in a series of other meetings. Results surface towards management – finally all Objectives need to be agreed upon by staff and management – no dictating. Typically 60% of the Objectives come from bottom-up and 40% from management.

The individual Objectives are defined by the individuals and discussed with the line manager. It’s the employee defining the personal Objectives – ensuring commitment and understanding the value brought in to achieve the overarching Objectives.

OKR's cadence - who does what and when?
OKR’s cadence – who? what? when?

Strategy – yearly

C-Level revisits the company strategy at least once a year and reports corrections and refinements back to the staff in an All-Hands meeting.

Tactics – quarterly

Short before a OKR period ends – typically a quarter – various combinations of management discusses and finally agrees on the next periods’ OKR’s. The combinations ensure free flow of information, results, concerns, objectives from top to bottom and vice versa. In an All-Hands meeting at the end of the period the achievements are reflected, graded and – most important – celebrated. A retrospective uncovers process flaws and potential improvements to be addressed in the next period. The All-Hands is also the place to communicate the OKR’s of the next period.

Operations – bi-weekly

The operation of the OKR process fully integrates with existing agile methods (e.g. SCRUM or Kanban). The agile review, retro and celebration is topped-up with further information about Key Results and where the organization stands reaching the Objectives.

Basics around OKR’s

Agree on 2-3 Objectives to focus the respective organizational unit – no more than 5 Objectives. Agree on 3-4 Key Results per Objective – take care to have them measurable with KPI’s and a numerical expectation. Keep the ratio 40% : 60% – 40% of the Objectives come from the management and – more important – 60% come from the basis. This ratio ensures high commitment and engagement amongst the involved individuals. All involved participants have to mutually agree on the Objectives, there is no dictating from management.

From a scoring and grading perspective aim for 60%-70% achievement per Key Result – this is an excellent value. Not too ambitious, but definitely a long stretch. 40% and less? Or 100%? Both are bad scorings. 40% or less indicates either the OKR was too ambitious, non-realistic or there was definitely a huge problem within the team. 100% means the OKR was not a stretch at all – more like a low hanging fruit.

The OKR’s are set quarterly and annually – but not set in stone. If conditions force a deviation from Objectives the team is free to decide to change the Objective – again with all participants’ agreement. Grading of Objectives happens every quarter. The OKR’s are defined at the company level, department and team level and also on an individual basis. The Objectives and Key Results are publicly available for the entire organization – all OKR’s, the individual’s included.

Ah, and finally. To keep the OKR’s effective and credible, to keep all people involved motivated and encouraged to deliver top performance, NEVER connect the OKR process with whatever employee performance process you might have in place – NEVER! Also, don’t associate OKR’s with money – get rid of the variable payment portion! If not possible to return to a 100% fix salary – don’t put money behind the OKR’s.

OKR’s and company values, purpose, vision and mission in context

OKR's, mission, vision, purpose and values in perspective - Where do OKR's live?
OKR’s, mission, vision, purpose and values in perspective – Where do OKR’s live?

A company producing value for customers strongly aligns in some ways. The organization defines their core values during founding. The values don’t change typically – they define the company and established by the founders. The purpose of the organization aligns strongly with the values and adapts with the management in place. A change in management means usually also a change in the purpose of the organization. The company vision holds for 5-10 years, the mission 3-5 years and the mid-term goals for around one year. The OKR’s account for roughly a quarter and align with the overarching strategic goals.

Scoring and grading of OKR’s

Each KR is graded individually and the average of the KR’s indicate the overall Objectives grading. There is no fancy weighing or calculation involved – every KR has the same weight and it’s simply the average. The sole purpose of the grade is to reflect the progress towards the overarching Objective. The goal is to reach 60% to 70% accomplishment for the Objective – reflecting the nature of a stretch Objective, but still being reachable. Receives an Objective low grades, the owner need to reassess the reasons for the low grades. What do we need to do differently to achieve the Objective? Is the Objective still valid? Still worth doing?

Grading on all levels reinforces the commitment on all levels towards the bigger company Objective. Each Objective owner scores the KR’s and hence the Objectives and makes the grades public – again on all levels. The OKR owners of non-individual OKR’s explain the achieved grades and potential adjustments for next quarter. The CEO grades the whole company and explains it publicly – as all OKR owners on team and department level.

OKR examples

Example for Personal OKR's
Example for Personal OKR with grading (Objective’s grade = average of KR’s grading)
Example for Team Level OKR's
Example for Team Level OKR with grading (Objective’s grade = average of KR’s grading)
Example for Company Level OKR's
Example for Company Level OKR with grading (Objective’s grade = average of KR’s grading)

Prerequisites for OKR’s in an organization

OKR’s sound just too good to be true, right? But they’re just a piece in a bigger jigsaw puzzle of methods. OKR’s are dangerous in a way that they can really hurt an organization if introduced wrong or at the wrong time.

Wrong introduction? Bring in some experts who have introduced OKR’s into organizations. Learn from their experience, let them support you in getting your organization behind you and your ambition to change the goal setting framework.

Wrong timing? “It’s never too late or too early.” Well, OKR’s live well in a culture with already implemented – or embraced – principles of agile management (think small teams, think network structures, think customer centricity). If your organization is still living in yearly performance reviews, hierarchical organizations, political games and strict command-and-control structures – DON’T implement OKR’s – it will very likely hurt more than it helps. Your organization must be ready to embrace, to enjoy, OKR’s.

Don’t crash your organization.

Marty Cagan, SVPG

Setting OKR’s surfaces organizational problems – deal with them

Ken Norton, Google

OKRs aren’t going to compensate for your culture.

Ken Norton, Google

Don’t link financial compensation to OKRs – NEVER.

Marty Cagan, SVPG

Other resources on OKR’s

Google and OKR’s

Example OKR’s

Developing OKR’s / Writing OKR’s


"Radical Focus" by Christina Wodtke

Radical Focus

by Christina Wodtke

"Measure What Matters" by John Doerr

Measure What Matters

by John Doerr

“Organisational Mastery” by Luis Goncalves – a Book review

"Organisational Mastery" by Luis Goncalves - a book review

Book review

I know Luis Goncalvez since quite some days and I was surprised when he gave me a copy of his book. I read his book “Organisational Mastery” on organisation transformation within a week and was really impressed. The book is split in two parts – the first part setting the scene with some theoretical background and the second part where the theory gets practical. The second part is a great mix of Luis experience in building organisations and real hands-on practical tips on how to do what in which sequence. The book is not meant to be a step-by-step guide for each and every organisation – but there are some patterns included, some practical tips which might support you in finding the right way to changing your organisation.

In “Organisational Mastery”, Luis bases the whole transformation – which sometimes appear to be quite radical – on five key elements:

1. Translating Strategy Into Daily Operations

Luis explains how OKR’s and / or Agile Portfolio Management are a key element in connecting Strategies and daily work, giving meaning to the small daily tasks and connecting them with the broader picture of a strategy aiming to reach an even bigger vision. Furthermore, he talks about the relevance of CoD (Cost of Delay) and how the understanding of this KPI can help in prioritization of activities. He also talks about the difference for an organisation if working on products or on projects. He also highlights how the goals and the strategy are aligned in a certain cadence.

Lean Portfolio Management (SAFe)
Agile Portfolio Management Definition and Key Principles

2. Optimise For Flow

Luis raises some criticism on typical hierarchies, no matter if line or matrix organisation. He’s a big proponent of mini startups within traditional organisations. No bi-modal thinking and working. Just create self-contained and independent mini startups around your key products to minimize dependencies as far as possible. Prerequisites for such an organisation is clarity on vision and the will to say “no” to non-relevant activities.

3. Continuous Improvement

Luis introduces the Organisational Impediment Board as a tool that allows the identification of issues, problems, in-efficiencies, … on a broad level with attention from all levels of people – including C-Level management.

Our Company Impediments Wall
Impediment Busting: Designing an Impediment Removal Process for Your Organization

4. Knowledge sharing

Luis positions the Communites of Practice (CoP) as a key element for knowledge sharing within an organisation of any size. These communities exist on all levels: team, product, organisational and external communities. An example for external communities are meetup and tech talks organised by the company for the community with the aim of getting new knowledge and talent attracted to the organisation.

5. Driving innovation

Innovation needs to be driven purposefully. Luis proposes the frequent execution of Design Sprints (Design Thinking, Google Sprints).

The whole book explains the five pillars and the effect on the organisation on a theoretical and practical level. Personally, I find the book very inspiring and hope to get some of the mentioned aspects implemented in an organization quite soon.

A definite must read book.

Foreword – personal notes on workshop “How to Create Tech Products Customers Love” – #1/11

Foreword - personal notes on "How to Create Tech Products Customers Love"

Foreword to my notes on Marty Cagan’s workshop “How to Create Tech Products Customers Love”

Here’s my foreword for a series of 11 posts summarizing my personal notes from Marty Cagan’s workshop “How to Create Tech Products Customers Love”. From 5th to 6th of June 2019 I attended the workshop by Silicon Valey Product Group (https://svpg.com/) „How to Create Tech Products Customers Love” in San Francisco (https://svpg.com/workshops/). The workshop was held by Marty Cagan himself.

I met Marty in 2012 already during my time as CTO at the German dating site “FriendScout24” where his advice turned out to be really valuable for our product development teams – and myself. Marty’s knowledge and personality stayed in good memory – since then.

My motivation to visit the workshop by Marty Cagan in San Francisco

  • To continue my continuous learning journey I booked myself privately into Martyworkshop to catch up on digital product development
  • For networking reasons I decided to go to San Francisco to have Silicon Valley people around me

Value for money – is the investment worth it?

  • I found the workshop to be worth every cent because it’s simply not enough to read the book. Serious product people should attend the workshop, ideally more than just one person from the organization
  • Especially, the information shared between the lines is valuable, unique and really helpful
  • Questions from the audience reflect your own level of expertise in this field
  • Marty’s individual answers help to solve unique problems not covered in the book or his blog

Preparation for the workshop

Book "Inspired" by Marty Cagan - Edition from late 2017

As a preparation I read the latest edition of Marty’s book “Inspired”.

“Inspired” by Marty Cagan – Edition from late 2017 — https://www.amazon.com/INSPIRED-Create-Tech-Products-Customers/dp/1119387507

Why these blog entries?

I decided to put my notes onto my blog to keep it preserved for my further reference. The notes in isolation don’t make too much sense. However, in combination with the book and the workshop my notes provide a lot of information between the lines. The handout for the workshop is only available in combination with the workshop.

The notes are quite comprehensive and I decided to split them into multiple blog entries for further reference. The split follows the structure of the workshop – and partially the book.

Intro & Root Causes of Product Failures – notes on “How to Create Tech Products Customers Love” – #2/11

Product Failures - notes on "How to Create Tech Products Customers Love"

These notes of Marty Cagan’s workshop “How to Create Tech Products Customers Love” introduces Marty himself and talks about root causes of product failures.


The way Marty successfully builds digital products is influenced by multiple methods and techniques. He describes himself as “only collecting technologies and methods which just worked at other places”. He sees himself as an evangelist for methods.

For him key influencing methods / approaches are:

  • Customer Development
  • Lean Startup Techniques
  • Product Discovery Techniques
  • Product Analytics
  • Lean UX Techniques
  • Design Thinking
  • Agile Methods

The origin of the overall workshop is from Marty’s time at Netscape. At the time the browser war was still open and it turned out that the common way of developing products – the way Microsoft did it at the time – didn’t work for the internet age any more. Most interestingly, most of the basic principles were defined at Marty’s Netscape time and were altered slightly until today.

“big bang” releases are those happening less frequent than every two weeks.

Root Causes Of Product Failure

Why product development typically fails?

From Idea to Delivery in WATERFALL process
From Idea to Delivery in WATERFALL process

IDEAS – The source of ideas

Typically, the source of ideas are customers, managers and other stakeholder of the product. These groups of people typically don’t know what’s possible to do today from a technology perspective. Furthermore, they don’t really know what they want or need until they see it. Hence, great companies involve their tech people in the idea generation process. They typically are the best source of innovation.

Apple builds tons of prototypes to lower the risk of failure building a device (e.g. iPhone).

BIZ CASE – Business Case Fallacy

The business case is positioned too early in the overall process. At such an early time in the process nobody has a proper idea on cost to implement the idea nor any idea on the benefit. All information is based on guessing or experience, no evidence on the assumptions can be provided at this time.


Typically, the product roadmap is confused with a committed list of features. Two reasons for the existence of roadmaps:

  • The leadership team of a company wants to ensure the teams are working on the most important topics
  • They want to know when it’s due for delivery

The BING team at Microsoft confessed they’re “only” able to ship 10% of their roadmap items “on time”.

Why’s that?

  • Roadmaps are not trusted by stakeholders because they don’t deliver on time
  • It takes 3-4 iterations until the items on the roadmap actually provide value – the “time-to-result” is ways more important than the “time-to-market”
  • Roadmaps are prohibitive to reach the real product goals since they’re too focused on features

But customers always ask for product roadmaps. What to do? Customers usually don’t want to have feature roadmaps, they want to get an understanding of the future product vision, where is it heading to?

REQUIREMENTS – The Role of Product

The typical requirement gathering job is no longer relevant in modern product development. The job of a Product Owner (as known from agile) is typically 5-10% of the role of a Product Manager. PO is the operative job working with the agile team in delivery. The PO and the PM need to be the same person.

The real work of product teams is not to optimize existing features, but to innovate, to create new solutions to specific business problems. The methods presented in the workshop aim to deliver winning products faster. Not through longer work hours, but a smarter and more predictable way.

DESIGN – The Role of Design

Design is referred to as UX, visual design, experience design. Typically, in waterfall models design is brought into the process ways too late. The waterfall-model enforces the “lipstick-on-the-pig”-model and is doomed for failure.

BUILD and TEST – The Role of Engineering

Software Developers provide only 50% of their value if being involved in build and test only. They need to be involved in product discovery as well, not only in product delivery. Outsourcing a whole engineering team (agency model) doesn’t work (see Hertz / Accenture case https://www.adweek.com/brand-marketing/accenture-seeks-to-dismiss-multimillion-dollar-hertz-breach-of-contract-lawsuit/).

BUILD and TEST – The Role of Agile

In the waterfall product development model the only place for agile methods is during build and test. It only lives in the engineering department.

DEPLOY – Output not Outcome

The whole waterfall process is tailored to deliver output and not outcome.

DEPLOY – Customer Validation Too Late

In the waterfall product development process the customer sees the product only after it’s deployed. Customer validate it by accepting or neglecting the product. The opportunity cost with this approach are extremely high and dangerous for the overall business!

The whole process takes way too long to validate the overall effort of building the product. Building a MVP which takes 4 month is ways too long. A startup needs 50-100 iterations to have a successful version ready for market fit. Typically, a MVP takes 4 hours to a few days. Microsoft has a patient leadership team. It takes typically 4-8 years to launch a product and 4-6 iterations until the product is really great (e.g. Internet Explorer, Bing, …).

“It’s not about processes; don’t be religious about process.
It’s the outcome to focus on.”

Marty Cagan

Steve Denning’s articles in Forbes and his article on “Understanding Fake Agile“.

Three Key Themes in Product Development


“The riskiest thing you can do is not to take risks.”

Diane Greene

Tackle risks up front – as early as possible. In digital product development there are four risks to address:

  1. [HARD] VALUE risk – will they use / buy it?
  2. [SOLVED] USABILITY risk – can they use it?
  3. [SOLVED] FEASIBILITY risk – can we build it?
  4. [HARD] BUSINESS VIABILITY risk – will our stakeholder support it? Will it work for the business?

The value risk and the business viability risk are hard to tackle, usability and feasibility however are covered with methods and tools.

It’s the job of the product manager to address these risks before engineers build the product.


“To innovate you need to collaborate.”

Marissa Mayer
The core of the collaboration: Product Manager, Product Designer and Tech Lead
The core of the collaboration: Product Manager, Product Designer and Tech Lead

Define products collaboratively, not sequentially. It is a big advantage to have teams geographically collocated – sitting in the same room ideally. If that’s not possible for whatever reasons the minimum setup is to have the Product Manager, the Product Designer and the Tech Lead at the same location. All other models simply don’t work.

Most times the innovation is driven by engineering (e.g. iPhone). A good example for all-on-site is balsamiq. A good example for all-off-site is Invision. Invision is a organizational setup where all people work remote – it’s part of the DNA. In this case, the distributed Product Manager / Product Designer / Tech Lead works – because of the culture of the company.


Focus on business results, not output. Performance is measured by results.

“As a venture capitalist, we don’t care how many features were shipped last quarter or last year. Instead, we look at the business results, and whether the team is building a product that customers love.”

Ha Nguyen

Ask yourself these questions:

  • Is the team setup to build features – or to solve real business problems?
  • Is the team empowered? Product teams exists to solve problems in ways that your customers love, yet work for the business.

This blog post is part of a series. It summarizes my personal notes of the workshop held by Marty Cagan “How to Create Tech Products Customers Love” from 5th to 6th of June in 2019 in San Francisco.

Key Terms and Concepts – notes on “How to Create Tech Products Customers Love” – #3/11

Key Terms and Concepts - notes on "How to Create Tech Products Customers Love"

Key Terms and Concepts

The three stages of a company:

  • Startup: getting to product/market fit
  • Growth stage: scaling to success
  • Enterprise: consistent product innovation

Discovery & Delivery

Discovery and Delivery
Discovery and Delivery

Discovery A rapid series of experiments that enable us to discover solutions to the problems our team is tasked to solve. The results don’t scale -> prototype.

The thinking behind Discovery: “FAKE IT to build the right product

Cadence: At Discovery we talk 10-30 iterations – per week!

Example video of the Nordstrom innovation lab showcasing Discovery (https://www.youtube.com/watch?v=2NFH3VC6LNs)

Delivery Building shippable products that provide the necessary scale, performance, reliability, security, and accuracy for us to release, sell and support with confidence. The results do scale -> product.

The thinking behind Delivery: “MAKE IT to build the product right

Cadence: At Delivery we see typically ½ – 1 iteration – per week.

Discovery and Delivery happen all the time in parallel (dual track agile). Discovery is rarely done by engineers, it’s usually done by Product Managers (PM) and Product Designers (PD). Engineers are busy with Delivery. PM and PD save 1 hour a day for Delivery. Engineers spend ½ hour a day for Discovery. The engineers spend time playing with the prototype, point to critical elements and think about ways to solve specific tasks in a better way.

Who owns what and the cadence of Discovery vs. Delivery
Who owns what and the cadence of Discovery vs. Delivery

The product vision is roughly 5 years out.


Objectives are usually set using Objectives Key Results (OKR). A typical objective might be “fix international conversion rate”. See: https://www.agile-minds.com/product-vision-objectives-notes-on-how-to-create-tech-products-customers-love/


MVP = Minimum Viable Product (better: Test, Prototype). It is the smallest experiment we can devise to try out an idea or tackle a specific risk in product discovery (usually a prototype; never a product!)

Product Market Fit

The smallest delivered product that we can sell, that meets the needs of a specific market.


Consistently delivering new sources of value to our users and customers – creating value


A low-risk, minor improvement to existing product – capturing value

This blog post is part of a series. It summarizes my personal notes of the workshop held by Marty Cagan “How to Create Tech Products Customers Love” from 5th to 6th of June in 2019 in San Francisco.

Product Teams & Product People – notes on “How to Create Tech Products Customers Love” – #4/11

Product Teams & Product People - notes on "How to Create Tech Products Customers Love"

Product Teams & Product People

“We need a team of missionaries, not a team of mercenaries.”

John Doerr

Product Teams

The “2-pizza-box” rule indicates a good sizing for product teams: usually 2-10 developers, one product manager and one product designer. One product manager for two teams (or more) is okay as long as there are no more than 10 developers in total.

Spotify is a good example for an organizational setup – teams are named “squads”. Besides the product manager, the product designer and the technical lead other squad-roles are e.g. User Researcher, Delivery Manager, …

Some other companies use the term “triad” to emphasize the product manager / product design / technology lead roles within a team.

A product team is

  • Small
  • Durable (formed for many years) – achieve psychological safety; enables relationships – critical for real collaboration and trust
  • Cross-Functional – allows team access to engineers expertise necessary for innovation
  • Co-Located
  • Measured by Outcome – shift from “release and forget” (feature delivered) to outcome (business result delivered)
  • Empowered
  • Accountable
  • Understands Business context

Product Manager

“Intellectually curious, naturally collaborative, plus plenty of grit.”

Lea Hickman

The Product Manager (PM) is responsible and accountable for the results of the product team. The PM must think like an owner. PM’s should be seen as future CEO candidates for the company by the current CEO. If not, the PM is the wrong person.

PM-work should be around 4 hours per day (Spend your time wisely!). Get rid of the meetings! The Product Owner (PO) part is the administrative part of the role and accounts typically to 10% of the work of the PM.

Good onboarding tool for PM’s: Fill in the product canvas / lean canvas: https://leanstack.com/leancanvas by Ash Maurya, Alex Osterwalder

Productivity Hack by Marty: AIRPLANE MODE – put messengers and other instant communication features into airplane mode  if you want to get work done.

Misunderstanding the role of the PM is the most common reason for the failure of this product development model.

Insider-Tipp by Marty: Subscribe to Ben Thompson’s “stratechery” newsletter (see: https://stratechery.com/).

The PM contributes deep knowledge of … THE CUSTOMER

The PM is the first person in the company to talk to if anybody wants to know anything about customers. Marty’s introduction into his first product role: “talk to 15 customers in the US and 15 customers in Europe”. These visits created the base line for Marty’s knowledge about his customers. He furthermore continued to visit customers and talk to them. It’s important to memorize: “KNOW THE UNKNOWN”. Visiting customers is great for networking inside the company and outside as well.

The PM contributes deep knowledge of … THE DATA

The PM spends the first 30-60 minutes of a day to look into the available product data. The PM is the acknowledged expert on product data.

The PM contributes deep knowledge of … THE BUSINESS

The PM knows all aspects of the business model and the underlying business. The PM knows the dynamics, the various stakeholder. Marty intentionally doesn’t say “The PM acts like the CEO of the product” because the way people act is precisely not the analogy. The PM needs to understand the various dimensions of the business – as the CEO does.

The PM contributes deep knowledge of … THE INDUSTRY

The PM is a domain expert and knows about competitors, trends and does regular SWOT-analysis.

Skills for a Product Manager

The Product Manager should attend these academic classes:

  • intro to computer programming
    help to understand the developers
  • intro to business accounting / finance
    help to understand the business side of the product
  • intro to statistics / data analytics
    help to analyze data

Israel has great product teams: everybody has to do military service and in there people learn to solve hard problems under stress.

“Like me, trust me, listen to me.”

Adi Soesan

Adi used to be a fighter pilot in Israel and was kind to people, earned their trust and soon they started to listen / follow her. PM’s need to do the same: be sympathetic, gain trust from stakeholders and people will start to listen to the PM.

Product Designer

“I love creating solutions, and I am optimistic at heart. If you put those together, you get a tenacious-seeming, “there has got to be a way!” to solve any problem mindset, even if it’s a problem I don’t understand at first, or that keeps morphing.”

Audrey Crane

The Product Designer (PD) is responsible for how customers and users experience the value provided by the product. PD’s are typically specialists in interaction design. They’re also not limited to wireframes and do not focus only on online. The PD is doing ideation work and prototyping with the team, is busy with usability and value testing and designs assets for the delivery.

Tech Lead / Lead Developer

The Tech Lead (TL) is the PM’s key partner and overall responsible for delivery. The TL has to have business sense, coaches engineers on the team, is responsible for the holistic view on the technology solution, is an active contributor to product discovery. The TL typically is a senior engineer, an architect or a dev manager.

Other Roles

  • Delivery Manager: project manager to remove impediments
  • User Researcher: qualitative learning
  • Data Analyst: quantitative learning
  • Product Marketing: interface between sales and product, usually more closely to sales channels – pricing is typically at product marketing – usually provided through external specialists
  • Architect
  • Quality Assurance: manual QA no longer that important – test automation

Delivery Managers take over the project management tasks of the work. The role of a SCRUM Master is part of the Delivery Manager role.

The decision if there is an architect – or not is up to the CTO.

This blog post is part of a series. It summarizes my personal notes of the workshop held by Marty Cagan “How to Create Tech Products Customers Love” from 5th to 6th of June in 2019 in San Francisco.

Product Vision & Objectives – notes on “How to Create Tech Products Customers Love” – #5/11

Product Vision & Objectives - notes on "How to Create Tech Products Customers Love"

Product Vision & Objectives

The Product Strategy executes the Product Vision and is framed by Product Principles.

“Be stubborn on vision, but flexible on details.”

Jeff Bezos

Product Vision, Strategy and Principles come from the leadership team! When initial founders leave, it’s time for a new Vision by the new leadership team.

Product Vision

The Product Vision paints the picture of what you’re trying to achieve. Typically, the vision is the single-best recruiting tool to attract talent. The vision inspires, is not a spec, is emotional and oversees 3-10 years.

  • Good example of a well formulated vision from Workiva

“We founded Workiva with you in mind. Our vision has always been to modernize the way our customers manage business data by connecting collaborators, documents, and spreadsheets. The platform allows structured and unstructured data to be aggregated and connected across reporting and compliance outputs, including presentations, spreadsheets, and reports.”

Product Strategy

The Product Strategy is the path to make the vision happen. The strategy is unique to every company. It is a tool to focus on specific segments (e.g. vertical market, persona, geography, capability). To succeed implementing the strategy it’s more important to have any sequential approach to the segments than on what to focus first. Apple chose the initial customer target group to be the iPod adopters for the iPhone launch. Only the 3rd iteration was targeted at the mass markets.

Tesla’s vision in the beginning was: “… our goal is to accelerate the advent of sustainable transport by bringing compelling mass market electric cars to the market as soon as possible …”. (Tesla’s vision today and an analysis of Tesla’s vision and mission in 2018)

To bring this vision alive, Tesla worked on a risk based product strategy. In a first attempt, they addressed the risk of building a battery that could power a car for 200 miles. Solving this problem produced the Tesla Roadster which is basically an electrified Lotus Elise. The next biggest risk to implement the vision successfully was to design and build a car. That produced the Tesla Model S. The final risk to tackle was manufacturing at scale – for the mass market. This produced the Tesla Model 3 – a mass market car for about 35.000 USD.

  • Risk #1: build a battery and run for 200mls –> Tesla Roadster (electrified Lotus)
  • Risk #2: design and build a car –> Tesla Model S
  • Risk #3: manufacture mass market ready (35.000 USD) car at scale –> Tesla Model 3

Homework for every (!) Product Manager: 1) Work with Google AdWords and book a campaign 2) Drive a Tesla.

Product Principles

The Product Principles describe the nature of the products you intend to create and reflect your beliefs about what’s important. They give guidance in cases of conflicts – e.g. eBay’s product principle: “buyer experience optimization is more important than fulfilling sellers needs”. In cases when the needs of the buyer and the needs of the seller conflict, eBay will optimize in favor of the buyer, because the most important thing eBay can do for sellers is to ensure a large number of happy buyers.

The Product Principles are not obvious, should be top of mind and they’re not laws, but violating should be conscious.


“Never tell people how to do things; Tell them what you need them to accomplish and let them surprise you with their ingenuity.”

General George Patton

Objectives & Key Results – OKR

A successful way to make objectives and expectations transparent to a whole organization are OKR’s – Objectives & Key Results. OKR’s are for defining and tracking objectives and their outcomes. OKR bring focus on business and product goals. The Objectives align with qualitative business and / or product goals and are synchronized with the overall strategy. The Key Results are quantitative measurable outcomes working towards the Objectives. OKR’s do replace feature roadmaps and ensure we’re working on the most important things. They also allow High Integrity Commitments for time critical objectives.

OKR’s were initially implemented by Andy Grove (then-CEO) at Intel. More on OKR’s at wikipedia or in Christina Wodtke’s book “Radical Focus”.

Two types of Key Results:

  • Aspirational results are meant to inspire thinking big
    Objecitve: “Speed up customer onboarding”
    Team: “with 50% confidence we’ll manage to get it down from 60 to 20 days
  • Commitment results are meant to be counted on
    Team is aked for a High Integrity Commitment: do enough research to figure the 4 risks (value, usability, feasibility, viability) to make the commitment

OKR’s – Key Points

  • Set the objective first, then the measurement
  • Focus on outcome, not output
  • Focus on organizational and team-level OKR’s
  • Make them public, visit your progress at least weekly
  • Focus on a small number of OKR’s

If the team misses all objectives, don’t fire them. Sit down with them an do a post-mortem – understand what happened and make them accountable.

Example – organizational OKR’s

Grow the core business‣ Total revenue + 10%
‣ $XX from new Partnerships
Diversify revenue‣ > 30% revenue from non-core business
‣ Product-Market-Fit (PMF) on one new expansion vertical
Improve customer satisfaction‣ Customer churn < 5%
‣ NPS > 55

Example – Team Level OKR’s (B2B)

Discover our core customer value (PMF)‣ 12 new customers on new product
‣ 8 reference customers (>4 new)
Dramatically improve end-user engagement‣ > 80 of licenses sold active after 30d
‣ avg. 3+ logins per user per week
Drive a step-function revenue increase from core‣ +20% top-line $ growth YoY
‣ Monthly / Annual ration > 4/1
Dramatically up-level our infrastructure‣ Customer can deploy PoC in < 5 mins
‣ >90% automated test coverage
‣ Reduce latency by 50%

Example – Team Level OKR’s (B2C)

Increase the organic user base‣ Increase per-day views by 20%
‣ 10% new users from viral referral
Improve end-user engagement‣ Avg. 3+ logins per user, per week
‣ Avg. 60+ minutes per user session
Simplify onboarding‣ Reduce avg. to 20 sec
‣ Increase task completion to 90%
‣ Retention +20%
Dramatically up-level our infrastructure‣ Automate build process
‣ > 90% automated test coverage
‣ Reduce latency by 50%

Don’t do this with OKR’s

Don’t crash your organization – it needs to be ready. OKR’s as a leadership instrument are great, if the surroundings are right. Successful OKR implementations need the right culture, they need companies with empowered employees, with empowered teams. If applied at any other organization, the culture will clash.

Don’t do individual or functional OKR’s. Focus on organizational and team-level OKR’s.

Don’t link financial compensation to OKR’s – NEVER. Every product person should have equity in the organization. Incentive based compensation is not good for people’s motivation.

This blog post is part of a series. It summarizes my personal notes of the workshop held by Marty Cagan “How to Create Tech Products Customers Love” from 5th to 6th of June in 2019 in San Francisco.

Product Analytics – notes on “How to Create Tech Products Customers Love” – #6/11

Product Analytics - notes on "How to Create Tech Products Customers Love"

Product Analytics

Don’t release anything without instrumentation! NEVER!

Marty Cagan

Collect product data as early as possible. Don’t save on data, collect generously. Make the information available freely internal to your organization – share data widely. Share findings in your data, be honest and report good news as well as bad news.

Product data inspires new product work, measures progress and allows to understand customer behavior. Most important, product data is the fundament to allow informed decisions. Collect data, find evidence that ideas work and let data influence your decision making process.

What can be measured?

  • Behavior (click paths, engagement)
  • Business (active users, conversion)
  • Financial (average selling price (ASP), billings, time to close)
  • Performance (load time, uptime, crashes)
  • Operational costs (storage, network, computing)
  • GTM costs (acquisition, programs)
  • Sentiment (NPS, C-SAT, exit surveys)
  • External sources (PR mentions, comments, social media)

Example – Experience Metrics – following the H.E.A.R.T. Framework

For a broader discussion of the H.E.A.R.T. Framework follow the link.

Happiness‣ actual NPS
‣ % satisfied users
Engagement‣ % active users of X / time frame
‣ avg. number key action per user
‣ avg. time between key actions
Adoption‣ adoption rate
‣ time to first action
Retention‣ retention rate
‣ mean time to churn
Task Success‣ completion time
‣ error rate

One key criterion for B2B services to move away from on-premise to cloud based services is that instrumentation comes basically for free. B2B has to relax on security, safety and privacy concerns – or find ways to implement their high standards in cloud services – but these businesses get a lot of analytics from the cloud provider – they know, what’s going on.

This blog post is part of a series. It summarizes my personal notes of the workshop held by Marty Cagan “How to Create Tech Products Customers Love” from 5th to 6th of June in 2019 in San Francisco.