TL; DR
A tweet by John Cutler made me think over two weekends, so I wanted to write about it. It ended in a much broader spectrum, overview of concepts, methods and statements than expected. I sure could have split it smarter into multiple posts, but wanted to dot the line between them how organisation influences action, culture and therefore product.
The initial nudge
This tweet by John Cutler made me think last week.
The persistent version was published later this week at the blog of Amplitude. I love this illustration about the distinction into learn, build, measure.
Important note to the graphics and blogpost.
These diagrams are meant to encourage conversations. Like all models, they are “wrong”. They are not meant to indicate maturity, or to imply that there is one right structure for all situations.
Personal Thoughts
For me, those graphics perfectly illustrate the variety of empowerment and responsibilities of teams, handoffs and delegations into teams. And yes, more combinations are possible, even if you think of a broader ecosystem or value stream.
It might trigger similar pain for people like me reading this, as team boundaries, handsoff and sphere of influence are visible. Those graphics show dysfunctional and toxic environments too, where command and control is a leading force hindering autonomy and freedom.
What is your product?
Once teams aren’t empowered and limited to serve “real customers” paying for their “product” to make a living, it is always critical for me to talk about “product”.
Marty Cagan came up with a definition:
Product = Customer x Business x Technology
[…] successful tech product has to solve for the customer, has to solve for our business, and has to solve for the technology.
Marty Cagan
Therefore it is important to understand the difference about what you’re building and what you define as a product: a component, a feature or a whole product for customers paying for the usage. Is it sold or internally charged? Enabling technology for the product? Supporting tool to contributing the real product?
So what: Delivery, Feature or Product team?
Marty Cagan has written a blogpost about Product vs Feature Teams.
How do you know where you are, ask yourself some questions:
- Are you provided roadmaps with prioritized features and dates, or are you assigned problems to solve with business outcomes?
- Is there role confusion between you and your designer?
- Is there role confusion between you and your delivery manager?
- Do you spend most of your day doing project management?
- Did you try using OKR’s and was it a mess, either ending up being rejected, or some contrived mashup of outcomes and features delivered?
- Do you have a team of missionaries or mercenaries?
- What is the level of accountability?
He also came up with a clear distinction:
Delivery teams are not cross-functional (basically just developers plus a backlog administrator product owner), they are not focused on outcome (they are all about output), and they are not empowered (they are there to code and ship).
Feature teams usually are cross-functional (at least some form of designer and some form of product manager), but they are still all about output and not empowered.
Product teams are cross-functional, focused and measured by outcome, and empowered to come up with solutions that work.
https://svpg.com/product-team-faq/
Try this, it is a great way to learn about your org system and find a lot of ideas what to improve immediately:
LeSS about teams and transitions
Then I re-found LeSS has a similar graphic, illustrating the ideal state of product teams even when they talk more about feature teams. After reading the article, I’m under the impression they talk about the same thing.
This is an example of the transition way:
The Elephant in the Room
Organisational Structure
Organising your product and value streams matters and is reflected in Conway’s law:
…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
M. Conway https://en.wikipedia.org/wiki/Conway%27s_law
Highly recommend to read more here.
That’s why I’m so passioned about empowerment of teams and people who build the product. For me this is the number one reason why agile transitions fail and people don’t contribute to their business and customers as they could.
Hierarchies are Yet Another Ache
The bigger the company is, the more you have to deal with Larman’s Laws of Organizational Behavior which are observations based on decades of consulting.
(1) Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
(2) As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
(3) As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, “religion”, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
(4) As a corollary to (1), if after changing the change some managers and single-specialists are still displaced, they become “coaches/trainers” for the change, frequently reinforcing (2) and (3).
(5) Culture follows structure.
Larman’s Laws of Organizational Behavior https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior
Separating disciplinarian management from operational product lead is essential for being successful.
Tweet
Lack of Trust
I might be wrong, for me it comes down to the lack of trust into people, teams and at a system.
The more interesting article written by John can be found here: Why Don’t They Trust Us?
I’ve tried to recap some ideas and views from Marty Cagan in older blog posts here and here. Nevertheless I highly recommend to read his book Inspired and the post about Empowered Product Teams. Empower your teams!
“People are allowed to do their thing.”
Tweet
Team and Alignment
And what is their thing? How would you balance alignment and autonomy? Spotify described it in this way:
Align through North Star and OKR
Find your own path, and create a star on the horizon for the direction. Amplitude has done a good job selling and articulating their way of product lead and process into the market.
Selecting your north star from the following games:
1. The Attention Game: How much of your customers’ time can you capture in your product?
Game categories of a good north star https://amplitude.com/blog/2018/03/21/product-north-star-metric
2. The Transaction Game: How many commercial transactions does your user make on your platform?
3. The Productivity Game: How many high value digital tasks can your customer perform in your product?
Amplitude posted their north star as an example here.
I participated a North Star workshop with Amplitude left with mixed feelings. On the one side it looks promising, on the other side it was somehow over-simplified. References in the usage of the North Star concept is missing.
There is a lot of criticism about OKRs nowadays which goes back to the lack of trust and pushback from management. Further recommendations about OKR:
John Doerr on TED
Bruce McCarthy – How Should Product Teams Use OKRs?
Tim Herbig – How to combine Objectives and Key Results (OKR) and Agile Product Management?
Politics, Ego and Fear
The biggest drawbacks I’ve learned in the enterprise theater: politics, ego and fear.
Note local agendas, back-channeling, more cooks, distrust, opacity, loss of morale, and cutting corners….all can be easily mapped to lapses in Empathy, Reliability, Credibility, and Apparent Self-Interest.
Sure you can find this in every environment, even in startups, small and medium business companies.
Try instead to to communicate what problem needs to be solved and why. My mantra for this:
Be open, be kind. Be a good example. Be the change you wish to see in the world. And try to find the best solution while collaborating with each other.
Tweet
See more here too: Be a good example. Treat others like you’d like to be treated. Be kind.
Change in Company and Team Organisation
Multiple systems point into organisational changes as a direction. Try to understand your existing culture first and try “to flip” changes fast.
Agilitrix and Michael Sahota
Reinventing Organisations by Frederik Laloux
This graphic is a kind of summary of the book by Frederik Laloux which I foind worth sharing. Of course more context would be needed, but it’s a great start to move ahead.
12 laws from BetaCodex by Niels Pflaeging and Silke Hermann
It is an evolvement of their work before with Complexitools, check out the English articles from Niels too: Secrets of Very Fast Organizational Transformation (VFOT)
Final thoughts
For some readers, there might be to less context and too much mix in sources. At least I hope it is inspiring for you to read and learn more about it and maybe start a conversation.
I’ll try my best to catch up with it and dig a little bit deeper into more details and clear posts.
Thanks,
Patrick
Patrick Sauerwein | @virtual_patrick 
One thought on “A Potpourri of Product, Organization, Team and Individual Thoughts”