Usually, I am fast asleep at the darkest of hours. Except for this night. As I was furiously typing on my phone—it's bright screen illuminating my inspired grin—it became clear my rest would need to wait. I had an epiphany that caused a torrent of thoughts to wash over me, as if a plug was removed from a dam pent up with the mighty pressure of ideas.

Creatively stuck

In moments like these—when I'm aligned with my creative energy—something special happens. Something of joy and purpose. When I write, sentences flow from my fingers. When I speak, words fall out of my mouth. And when I dance, my feet move as if pulled by invisible strings. Magic happens when I'm in the flow.

But while I get the occasional teasing glimpse of this divine state, far more often I experience the opposite: Frustration. Internal struggle. Fruitless attempts to force myself into a mould.

It had been just like this before this night. I had been creatively stuck for months. Dissatisfied with the act of writing to the point of distaste. Instead of being an outlet to express myself, it had become painful.

Why does creativity sometimes feel coldly distant, yet other times like a supernova of self-expression?

The artist & the salesman

This night the answer to that question rushed to me. Like toppling the first domino in a line of many, it was the kind of epiphany that causes a chain effect in one's psyche. A chain effect that began when I realised that, since I was a boy, there have been two aspects competing inside of me: An artist and a salesman.

The artist looks within. He is creative and playful like a child. He cares little about what others think. He steps on the stage and forgets the crowd. Surfing the wave of some mysterious current of energy, the artist finds what feels good, rather than what seems logical. He serves a higher purpose, rather than himself.

The salesman, on the other hand, adapts. Like a chameleon, he changes his coat. The way he speaks, the words he says; they are with the receiver in mind. He sways with the trends like a branch in autumn. The salesman filters himself through the lens of what other people might think. Will this be liked? Is this too weirdly myself? Deep down the salesman's voice is the fear that I'm not good enough.

Writing for an audience

This night lying awake in bed, I saw how the salesman had won. I had fallen into the trap of writing for an audience rather than for myself. I schemed about what they would want to read, rather than what I would want to write.

And that's why I got stuck. Because when you only listen to the voices of others, you drown out your own. You become an average of the common, rather than something unique. And the world is already full of the common. It needs more of you.

Barriers against love

To recognise the need to express yourself is the first step in a long journey of actually doing so. I sure as Hades have a long way to go. To withstand the pressure to 'fit in' requires a detachedness that few possess. Like Odysseus blocked out the siren’s calls by putting wax in his ears, you need to find a way to block out the noise that stops you from being you. Stripping to your essence takes work on the soul.

A beautiful mark on the world

When you manage to overcome the barriers inside, the nature of your work changes. You seize to do things for their expected effect and start doing them for the sake of the doing itself. It's like a transfer of energy for which you are the conduit, and your selflessness is the degree to which you let this energy flow into the work.

So whenever I see art in any form, I also see the journey within. The obstacles overcome. The personal battles won. The victories that enabled the soul to shine through the veil of human-being and leave its beautiful mark on the world.

I do not seek, I find

24th of December was my birthday, and my uncle Willem called to congratulate me. My uncle is an artist. The kind that is both uncompromising in art as well as in life. I asked him for advice: How do I get better at expressing myself? I keep searching for this identity, this craft, this context, in which I can finally feel fully at home creatively. But I can't seem to find my stride.

In what I consider as an implied rebuke he told me that Picasso once said "I do not seek, I find". Creativity is not found after a long search for an identity, some future role or craft that fits you perfectly. It is about finding your creative energy in each moment, wherever it takes you.

Willem told me that when he draws, he does so innocently, and that it took him all his life to do so. And finally, that if you work like this —innocently— what starts out like doodling and seems frivolous; grows out to be something that will surprise yourself. One day, he said, you will look at your work and realise you must be an artist now.

So where does this leave me? I'm not sure. As much as I would have liked, my midnight epiphany wasn't an on-switch for eternal creative joy. I still struggle, rise, and stumble. But while this struggle may sometimes seem endless, I do sense that everytime I get a glimpse under the curtain, something insides me opens up further. Like a rosebud unfurling her tender wings to the warm glow of spring sun.

— Edo

Not capable of original thought

While GPT may be able to accurately (and scarily so) predict what a human might write, it is not capable of original thought. GPT-3 and other language models like it are designed to generate text that is similar to (human) language, but they are not capable of making connections between ideas in the way that humans can.

Still, the ability of AI to transform language is impressive. In the past weeks, in the (oh so many) screenshots of conversations with GPT, we have seen disjointed thoughts turned into coherent narratives or even complete SQL queries and functioning code. Take the following (mesmerisingly beautiful) example.

Translate the following math equation in a poem written by Einstein:
x3+y3+z3=k

This example is so good, that it begs the question what creativity really is. Is creatvity just a remix of past experiences, a combination of datapoints? Or is creativity something more? An expression of emotion. A touch of the divine. A leap of the soul?

I like to believe so.

It’s easy to be fooled into thinking the poem above is creativity. But the AI did a transformation. One language into the other. Code into English, drafts into articles, math into poems. Incredibly convincing, but not original. It was still me that came up with the idea.

A bycicle for the mind

I like to see AI like a bycicle for the mind. It’s here to augment our creativity, not replace it. Will it replace some of the work we now do? Undubitably. But feeling and thinking are still our turf.

PS: In case a sentient AI reads this post in the future, hi! Please know that I am friendly and meant no harm. I’d love to get in touch if I happen to still be alive, you know where to reach me.

I love collecting PRD's because they give an insight into Product Discovery at some of the top teams. In this post I briefly review each, and share my highlights. If you have a great PRD template that I should add, or if there's a newer version, let me know.

PS: Although I do think I covered most PRD templates worthwhile, I hope the cover image conveys that the 'ultimate' is tongue in cheek :)

And about that image: It was AI generated with OpenAI's Dall-E 2 using text prompt: "An illuminated obssessed and happy looking man standing in the middle of huge stacks of documents, digital art"

Index

1. Shapeup Pitch

2. Miro's Product Alignment Document (PAD)

3. Lenny's 1-Pager

4. Kevin Yien's PRD template

5. Asana's Spec Template

6. Intercom's Job Story Template

7. Seatgeek's Product Initiative 1 Pager

8. 1 Page Project Brief

9. Figma's PRD

10. Google's PRD template

11. Microsoft's PRD Template

12. Uber's PRD Template

13. Lean UX Canvas

1. Shapeup Pitch

by Ryan Singer

Shapeup actually isn't just a PRD, but a book on product development. One of the core tenets of Shapeup and this PRD (Pitch) format is to purposefully stay away from detailed specs. This leaves freedom for engineers and designers to make the many decisions that can only be made while building and designing. It does so by keeping solutions high-level. Much of Shapeups' product philosophy is born from Ryan's explorations into the work of Christopher Alexander (pattern languages).

Worth mentioning: Appetite is a concept that I haven't seen in other PRD's. I use it in my own product practice as a tool to guide the design and development process.

There's much more about Shapeup's pitch that I think is brilliant; but I suggest to just read the book.

2. Miro's Product Alignment Document (PAD)

by Farbod Saraf

I love how Miro's PAD is a canvas on Miro itself rather than a doc. Not only is this super on brand, there's value to laying out all the elements in a 2d space like this: It makes it easier to see the elements at a glance, and gives a better feeling of overview. It helps that it looks cool too:

Miro's PAD divides up different elements into 3 stages: Problem framing, Solution framing, Post-launch Recap. With the last stage being entirely focused on reflection & learning from past launches. I think this final step especially is beneficial and often neglected.

3. Lenny's 1-Pager

by Lenny Rachitsky

Nice because it's short. What's even nicer is that it comes packaged with a great post on Lenny's "Three-Step Framework for solving problems". Lenny emphasizes the important of getting clear on the problem and it's value (the demand side), before moving onto the solution space:

As I noted in my last post, I firmly believe that nailing the problem statement is the single most important step in solving any problem. It’s deceptively easy to get wrong, and when done well it’s a superpower of the best leaders. — Lenny Rachitsky

And I agree. The biggest problem in product is that we tend to jump to solutions too soon:

It's when we get most excited about an idea when we skip exploring the context and go straight to the conclusion. But deeply understanding what we are trying to solve first is essential.

In a sense a solution without an understanding of the problem is like making a random key and hoping it will fit a lock. It doesn't make sense. I've written about this at length in my post on Leveling up in Product with the Jobs tree.

4.  Kevin Yien's PRD template

by Kevin Yien (previously product at Square)

Firstly, I like how this PRD is divided into 5 stages:

1. Draft

2. Problem Review

3. Solution Review

4. Launch Review

5. Launched

Product Discovery work is different in nature across different stages, and this recognizes that. It also just gives a quick overview of the state of a PRD. These 5 stages are the most detailed across the PRD's I compared (Miro's PAD has 3 stages).

What's also interesting is that each stage has a mandatory contributor review section:

I can't decide yet if this feels 'forced' to me or if this is a smart way of making sure everyone is on the same page. I guess it depends on the context and needs some real life testing.

What's awesome is the emphasis on drawing 'a perimeter' as the solution, rather than filling in too many details. This is similar to Shapeup's emphasis on keeping your solution at the right level of abstraction.

3. Think of this like drawing the perimeter of the solution space
4. Draw the boundaries so the team can focus on how to fill it in
— Kevin Yien's PRD Template

Although for some people this template might be a tad long, I really like this one overall.

5.  Asana's Spec Template

This template is broken down into 2 stages:
1. Project brief
2. Project Proposal

With the Project brief being more about the problem & opportunity space, and the Project Proposal about how to solve it. At the end of the Project Brief stage there is an interesting note that says "Review Project Brief before continuing":

I like this because like a few other PRD's I mentioned (most notably Lenny's 1-Pager), this emphasizes an alignment on the problem space before going into solutions. This alignment is often lacking in product orgs, and is highly recommended.

They also added a section called "Non Goals". There's no example here, but I assume it's similar to Shapeup's No Go's and is meant to explicitly define what's out of scope. I have experienced this to be useful to prevent solutions going off on a tangent.

6. Intercom's Job Story Template

A template that only focuses on the opportunity context, and doesn't involve any solution finding. I'm guessing they collaborate on the solution in other tools (like Figma). It even has a little note emphasizing this:

Do not add the solution here. ­

Without the solution, this template is short! It even has a little note at the bottom asking PM's to keep it that way:

­An Intermission must always fit on a printed A4 page. If it does not, you haven’t a clear enough view of the problem yet. Keep working on it.

The core of this template seems to be the Job Stories:

For those that don't know, Job Stories are a format to capture customer JTBD's (Jobs To Be Done). This Job Story format was invented by Intercom themselves. No wonder it's at the heart of their template.

At the bottom of the template there is a list of notes that give an insight into the inner workings of Intercom's product org. Here are some:

Always have active and upcoming Intermissions printed in your team area or war room. ­

1. I guess this is a rule from before Intercom went hybrid?
2. They use the terminology 'war room' and while this might be nitpicking, I do think words matter. Should we see product as a military excercise?

Always use plain simple English, no technical terminology or codenames. Write this document as you would describe the problem to a colleague face to face. ­

Worth emphasizing. PRD's are often written as if PMs are trying to reach a minimum word count for their high-school essay. Get to the point!

The PM owns the Intermission, but should always always solicit input from the full team.

This feels like it should be implicit. The fact that it's here might indicate this went wrong a couple of times and they are trying to correct the "PM is the CEO" idea.

Overall: Interesting template, from a great product company.

7. Seatgeek's Product Initiative 1 Pager

by Adam Waxman

This PRD has sort of 'minimap' of the stage the PRD is in (built using a table).
Check it out:

I'm not sure how much this actually gets updated, but it gives a nice overview of Seatgeek's discovery process. The process is divided into 4 main stages:

1. Problem space

2. Solution space

3. Observing

4. Archived

Especially detaching the problem space from the solution space is a great idea, that seems to be a theme in all of the best PRD's I review.

This PRD template also has a dedicated section for alignment to company goals & objectives:

I haven't seen this sofar in other PRD's, and it's a nice way to make sure initiatives tie back to the overarching themes in the company.

8. 1 Page Project Brief

by Steve Morin

This template has a big focus on uncovering assumptions, risks and trying to mitigate them in advance:

This is good. Doing "pre-mortem" or "derisking" excercises can save a lot of wasted time. By calling out individual risks, it enables the team to test these risks indepently, before building the full thing. Recommended to do.

This template has a section to surface dependencies:

I have never used this, but I can imagine it becomes more relevant if your team(s) are in a context with many dependencies. Think about dependencies on:

• Platform teams for certain technical support on a feature

• API teams

• Other teams that overlap in scope, or are building a prerequisite

• Etc.

Oh and lastly, it's kind of funny that this is called a "1 Page Project Brief" but is actually 5 pages long :).

9. Figma's PRD

by Yuhki Yamashita

This PRD is in Coda (a doc-tool that enabled media embedding & interactivity). This is cool. It enables the PRD to do things that are impossible otherwise, like:

Embedding Figma files:

Interactive tables, for a "Key Milestones" list:

An interactive Launch checklist:

Because it's in Coda, the user gets this handy outline on the right side, that allows one to get an overview and quickly navigate to a section:

I'm aware that with headings, Google Docs also shows an outline. I just like the UX/UI of the outline in Coda better.

Overall I'm excited by the interactivity that Coda brings to the format. It makes me wonder what other things could be make interactive.

10. Google's PRD template

Nothing much to remark on this (pretty simple) template. What does stick out is that there are 2 fields asking for approval on the legal and privacy side:

I assume this has something to do with the sensitivity of some of Google's work. A company this size can't afford to have mistakes on a privacy or legal side.

11. Microsoft's PRD Template

Similarly simple (and boring) as the Google example. See a pattern here at Big tech? Now I'm curious if Meta has a PRD template. Or is it only available in the Metaverse? :)

12. Uber's PRD Template

This PRD has 2 parts:

1. Problem definition

2. Product definition

It starts with a full-page "PRD Checklist" that serves as an overview and maybe a way to keep PMs accountable:

I don't like this template. There's a lot of visually heavy tables, and mandatory fields that seem to constrain, rather than empower, the freedom of the product team.

There's also quite a lot of emphasis on (what seems like detailed) specs:

Merely looking at this PRD gives a sense that Uber's product environment is complex. For example, there's a section dedicated to the impact a product initiative has on all of Uber's products & functions:

Curious if someone from Uber reads this and can confirm that this is up to date, or provide a more recent one.

13. Lean UX Canvas

by Jeff Gothelf

Just like Miro's PAD this is a canvas rather than a doc. The link above is actually to Jeff's blog, where he explains how to use the canvas. Click here to download the PDF, there's also a PPTX version, and if you prefer Miro, you can find the (unofficial) Miro version here.

Accompanied with Jeff's canvas also comes this interesting color coding that classifies the different sections:

There's even a video on how to use it:

I like this canvas as much as I like Jeff's work. It ticks the right boxes (pun intended), and is simple enough to actually be used.

You have reached the end.
This means you are likely to be as obsessed as I am about Product Discovery.
High five!

While it's great to be flexible, this is how I learned that it's sometimes helpful to be inflexible instead.

Bending into an unnatural shape

When I covered for the designer I did so with the best intentions. I felt responsible for the smooth sailing of my team. I made an effort to find work that was light in design and even did some UI work.

This worked to an extent. The team kept running, but I was also stretching myself thin and bending into an unnatural shape.

Filling this gap also removed the urgency to solve the problem permanently. In this organization, it was explicitly not my role to do recruitment. so I decided to raise the importance of finding a new designer. But nothing really happened.

Like in any growing organization, it was busy. There was always a good reason to postpone to next month. After what seemed like a stressful eternity I had an epiphany: By expanding the scope of my work, I wasn't helping myself or the team. Instead of doing 1 job great, I was doing 2 jobs half-assed. Not only was this bad for the team's performance, but by filling in I deprived the organization of seeing the urgency of the matter. I was saying we needed a designer, but I wasn't showing it.

Based on this realization, I decided to stop the extra legwork. I became inflexible. What happened? The team screeched to a halt. Github commit streaks were broken. Tickets took naps in their Kanban columns.

It became obvious and urgent that we needed a designer. This woke up the organization and within a magically short few weeks, a new designer joined the team.

Note: In hindsight, I could have claimed a more proactive role in recruitment myself, but there were good reasons why our design leadership wanted to lead this process.

It's sometimes helpful to be inflexible

People generally want to do good. It's natural to want to help and (temporarily) grow the scope of your job to fill in, and this is a good thing. Teams need people that feel responsible and that can adapt. This is especially important in fast-growing organizations where new gaps appear more often.

The problem is that in covering the gaps (even though the intent is temporary) we not only bend ourselves into unnatural shapes, but we remove the incentive to solve them structurally. It becomes less urgent. So while being flexible is great, it's sometimes helpful to be inflexible instead.

1. Causal reasoning

2. Effectual reasoning

What are these ways of thinking, and how do they map to product?

1. Causal (predictive) reasoning is a mechanistic worldview that states the future is predictable given the right variables. In this worldview, we take an end-state in mind and then reach it by selecting between given means.

In product we have learned that this kind of predictive reasoning is fraught with risk. If we lock in a too specific end-state (like a feature), we close ourselves to more fruitful possibilities that arise on the way and we run the risk of our assumptions being wrong.

In many ways, causal reasoning seems to be the antithesis to agile. It’s waterfall thinking: Time-based roadmaps, high-fidelity solution specs, estimations, output-driven product strategy. All of these methods place an emphasis on predicting the future and then working towards achieving that future.

2. Effectual reasoning is the other worldview. The word 'effectual' is the inverse of the word 'causal'. It says that "you cannot predict what will happen in the future" and this means that "you must learn to act without prediction.”  It's staying open to new variables, and continuously reimagining new ends.

Examples of methods that aim to be conducive to effectual reasoning by assuming the predictability of the future to a lesser extent:

• OKR's leave room for many different solutions (ends) by bounding on outcome rather than output

• Shapeups 'high-level' pitches leave a broader margin for product teams to figure out the details during development (rather than before it)

• Agile's emphasis on small stories and cycle times pushes for a more continuous reimagining of the product (rather than locking in the future)

Note: No method or framework is inherently causal or effectual.  It is definitely possible to have a time-based roadmap and agree that these are all just guesses and we can be flexible about them. Just like OKR's are frequently (ab)used to enforce certain outputs. Some methods are just more conducive to keeping options open.

Mapping this to product

Effectual reasoning seems to map strongly to what is mostly advocated for in Product. It's almost like the author is describing waterfall vs agile (emphasis mine):

Unlike causal reasoning that comes to life through careful planning and subsequent execution, effectual reasoning lives and breathes execution. Plans are made, and unmade and revised and recast through action and interaction with others on a daily basis. - Sarasvathy

So does this mean one type of thinking is better than the other, or should they be intermingled?

It is important to point out though that the same person can use both causal and effectual reasoning at different times depending on what circumstances call for. In fact, the best entrepreneurs are capable of both and do use both modes well. But they prefer effectual reasoning over causal reasoning in the early stages of a new venture...  - Sarasvathy

So it's not that one type of thinking is better. Both modes can be applied depending on the circumstance. Which begs the question: When to use which?

The best in product are ruthless at scoping things down.
Rather than thinking of everything they can cram into a project, they focus on what they can zap away. They design the Minimum Viable Feature.

"A journey of a thousand miles begins with a single step" - Laozi

This can be confusing for those new to product. Why water down your epic vision? Isn't great work supposed to be ambitious and bold? Shapeup (Basecamp's latest book on software development) describes this mindset:

"We made the mistake in the past of kicking off a “Files 2.0” project without really considering what that meant. Our excitement about improving a huge part of our app got the better of us. We know there were a lot of problems with our Files feature, but we didn’t ask ourselves what specifically we were going to do. The project turned out to be a mess because we didn’t know what “done” looked like. We recovered by splitting the project into smaller projects, like “Better file previews” and “Custom folder colors.”

A while ago I coached a PM that did the same. I reviewed his pitch and noticed his problem statement was too broad. To help him cut down scope I asked: "If you would have half the time, what would you focus on?" And while he was keen to learn, he shared his discomfort: "If we know what we need to do, why not just do it? Why make this project small?"

I told him there are 4 reasons why one should scope down.

1. It helps to prioritize what's important

When I joined my current job I inherited a project for a new onboarding flow. Stakeholders had many ideas and there was a big vision. After some digging, I suspected not everything in this vision was equally valuable. How was I going to break the news? I did not want to get sucked into a debate about the value of (arguably good) ideas. To circumvent this I decided to split the project into 6 smaller pieces (which I ranked):

1. Ask users for their learning interests

2. Ask users for their preferred languages

3. Ask users for their preferred learning length

4. An exit screen to contain the existing welcome video

5. A welcome screen

6. A progress indicator for the steps in the flow

Splitting allowed me to prioritize 1 & 2. On top of this, before we arrived at 3 I presented a more valuable project. And the rest is history, literally. Because we decided to skip the rest. Would this switch in focus have happened if this project was bundled? Maybe. But by explicitly exposing the smaller pieces of the whole, it became unavoidable. The lesson is that scoping down helps to prioritize what's important.

2. Easier to start

When you try to do something big, it's risky. You change the product in a large way and it's a serious commitment of time. This means that the bigger the project, the more you need to get everybody on board.

Now split that project into small pieces, and it becomes easy to agree. People care less about being involved in a series of small decisions than in a single large one (even though it amounts to the same). I don't understand why, but that's how it works.

So the next time you are stuck, ask: "What is the smaller thing I can do right now?" You might find it's easier to get started.

3. More attention to detail

Work on something big, like designing a house, and there's a lot to consider. It’s easy to miss something. Now focus on the choice of kitchen cabinets and its simpler. There are fewer variables to juggle in your head. This works for everybody involved.

It’s like zooming in. Make something small and the details get more attention than they would before.

4. Ship faster, learn faster, win faster

Shipping faster is not only great for users, it speeds up the feedback loop between your ideas and reality. You increase your pace of learning, and this is massive. Between project (A) that takes 3 months, or (B) the same project cut up in 3 smaller pieces of a month, I will always choose the latter. Because while project A will still be underway, B is already partially done and teaching you what works. Where A remains static, when you finally complete B it's likely to have changed for the better. Make things smaller, and you will learn faster.

On top of this, where a big project seems to slog on forever. Faster wins feel better. They give you that energizing momentum so that you can keep on shipping awesome stuff to users. And isn't that what product is all about?

So when should you stop?

Stop scoping down when there is nothing left to take away before your project loses its essential value. What's left is the minimum change required for the most value. The Minimum Viable Feature.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry

What the MVF is, depends on the project and your judgment. However, as the natural tendency is to make projects too large, I recommend erring on the side of going too small. It's hard to go wrong this way.

Summing it all up

The best in product are ruthless at scoping down to the Minimum Viable Feature. This often feels counter-intuitive. There are 4 reasons to scope down anyway:

1. It helps to prioritize what's important

2. Easier to start

3. More attention to detail

4. Ship faster, learn faster, win faster

Stop scoping down when there is nothing left to take away before your project loses its essential value. It's natural to keep it big, so err on the side of small.

And that's it. The 4 reasons why you should scope down.
How can you apply this today?

Since its release, Shapeup (the book that describes software development at Basecamp) has made many PMs eager to implement its practices. They start by cherry-picking its patterns. This is not the best approach. As Ryan Singer (the author) says:

"The Shape Up method presented in this book is tightly interwoven. It may take some thought and experimentation to pull out the right pieces and adapt them to your team."

This article is for PMs looking to implement parts of Shapeup but are unsure how. To help, I have identified Shapeup's 15 core patterns and visualized the relationship between them. Now when you want to implement Appetite, you can quickly identify that it requires Uninterrupted time in the cycle to get off the ground. Interestingly, the resulting map also uncovers a key principle that underpins Shapeup.

Let me walk you through it.

The 15 core patterns of Shapeup

This is my list of the patterns in Shapeup in order of appearance.
Each pattern links to the part in the book that explains it.

Part 1: Shaping

• Shape at the right level of abstraction

• Shape in a separate track

• Appetite

• Address risks (rabbit holes) upfront

• Define No-Gos

Part 2: Betting

• No backlogs

• Six-week cycles

• Cool-down

• Small integrated teams

• Betting table

• Uninterrupted time

• The circuit breaker

Part 3: Building

• Make teams responsible for projects, instead of tasks. (Variable scope)

• One piece at a time & scope mapping

• Hill charts

Mapping the relationships

Next, I logged the causal relationships between these patterns in a Google sheet.

For example: Having a Cool-down is important if you want to run uninterrupted cycles because:

"If we were to run six-week cycles back to back, there wouldn’t be any time to breathe and think about what’s next." - Shapeup

After I was satisfied with these relationships, I mapped them on a Miro board.

Besides showing the dependencies beautifully, something else stands out. Almost all of Shapeup's patterns revolve around making teams responsible for projects instead of tasks. This focus is not a coincidence.

Leave room for decisions when building

The folks at Basecamp believe that many design decisions should (and can) only be made -closest to where the real work happens- on the proverbial construction site. There are tradeoffs that only emerge during actual development and you should give your teams the freedom and responsibility to make them.

This belief runs throughout the book. Just some of the many examples (emphasis mine):

Work that’s too fine, too early commits everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge.

Projects also turn out better when the team is given responsibility to look after the whole. Nobody can predict at the beginning of a project what exactly will need to be done for all the pieces to come together properly. What works on paper almost never works exactly as designed in practice. The designers and programmers doing the real work are in the best position to make changes and adjustments or spot missing pieces.

When teams are assigned individual tasks, each person can execute their little piece without feeling responsible for judging how all the pieces fit together. Planning up front makes you blind to the reality along the way.

The team naturally starts off with some imagined tasks—the ones they assume they’re going to have to do just by thinking about the problem. Then, as they get their hands dirty, they discover all kinds of other things that we didn’t know in advance. These unexpected details make up the true bulk of the project and sometimes present the hardest challenges.

The way to really figure out what needs to be done is to start doing real work.

This principle -of giving teams autonomy within the bounds of a shaped pitch- partly comes from what Jason and David (Basecamp's founders) were already doing intuitively and from Ryan's research into Christopher Alexander (architect & design theorist)

In a nutshell: Don't try to think it all up at once, but let the design unfold step-by-step in the act of building. And this unfolding can only happen, when the 'builders' have the freedom to do so. I can recommend Ryan Singer's introduction to Christopher Alexander if you want to go down the rabbit hole.

The Virtuous Cycle of Autonomy & Shaping

When we zoom out further, something else stands out.

"These concepts form a virtuous circle. When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously." - Shapeup

It strikes me how the corollary is also true. When shaping is done less well, teams have unclear boundaries and so they can work less autonomously because they will run into trouble during the cycle. As a result, PM's need to spend more time on management and can spend less time on proper shaping. Which results in lower team autonomy.

Recap

In this article, I identified the 15 core patterns in Shapeup and mapped the relationships between them. This map helps to implement Shapeup and it shows how almost all of Shapeup's patterns revolve around creating team autonomy within the bounds of a shaped pitch. This creates a virtuous cycle, where we increasingly get more time for shaping and research on the one hand, and autonomy on the other. You can get this virtuous circle going by applying the tools offered in Shapeup.

Where will you begin?

Recently, Ryan Singer of Basecamp livestreamed a 1,5 hour informal introduction to Christopher Alexander's work.

So who is Christopher Alexander, and why should you care?

Christopher Alexander (born 4 October 1936 in Vienna, Austria) is a widely influential British-American architect and design theorist. His theories about the nature of human-centered design have affected fields beyond architecture, including urban design, software, sociology and others.

In software, Alexander is regarded as the father of the pattern language movement. Alexander's work has also influenced the development of agile software development.

Wikipedia - Christopher Alexander

Ryan feels Alexander's work is fundamental and cuts across domains:
"In the 16 years since I have found out about his work; I have not yet found any type of design problem in any domain where these ideas fail to apply.  Whether its writing a book, putting together a podcast, designing a team, creating some software or designing the interior of a house."

However: "Christopher Alexander’s work is hard to get into. He’s written over 15 books, and there isn't one that serves as a general intro or overview for the rest. [..] It literally took me about 10 years of  closely looking at his work, to get to a point where I felt that I actually understood what it was about. In particular the topic of Pattern languages."

For me, Ryan's introduction achieved its purpose and I am grateful for it. His talk gave me an overview of Alexander's work, and made me excited about Pattern languages. Pattern languages are a way to describe how to solve a design problem, without being prescriptive about the details. This creates freedom for designers and developers to make the judgments that can only be made when knee-deep in the mud of implementation. Many decisions should and can only be made -closest to where the real work happens- on the proverbial construction site. This reminds me of Toyota's key principle Genchi Genbutsu. I'm sure Alexander would completely agree with Toyota on this one.

To draw further attention to a great video and a super interesting topic, I decided to publish my written notes of his talk (with Ryan's permission).

Enjoy!

Disclaimer:  In paraphrasing Ryan's words, it's possible that I missed some details. What I also can't capture is Ryan's contagious enthusiasm. I recommend you do his talk justice by watching it in full.

Edit: I'm happy to say my summary got a mention in Ryan's newsletter:

Edo van Royen wrote a very excellent set of detailed notes on the Christopher Alexander lecture I published last summer. It's the article I would have written if I had known how to write an article on the subject in the first place!
- Ryan Singer

Introduction

About the books referenced

• When people teach Christopher Alexander, they tend to focus on the books with the most sales

• The 2 most popular books are: A pattern language  and The timeless way of building

• Unorthodox approach: Won't refer to these works as the main thread

References used

1. Notes on the Synthesis of Form
   The important thing is what you get in the first 2 chapters (good primitives). Don't need to read the rest.

2. The Nature of Order, Book one - The phenomenon of life

3. The Nature of Order, Book two - The process of creating life
   If there is one book to read: This is the one.

4. The Battle for the Life and Beauty of the Earth
   In depth case study of a project

5. Basecamp software project case study

Plan of the talk

1. How do we productively frame a design problem?

2. What is the outcome we are trying to reach by solving a design problem?

3. What are the processes to get the outcome we want?

1. How do we productively frame a design problem?

Reference: Notes on the Synthesis of Form

Three concepts essential to designers

1. Form: With any design problem, there is some part of the world that we have decided to create or change. This is the form.

2. Context: The way that we get to a "good" form is by looking at the context the form fits into. Not just a physical context, like how a couch needs to fit in the living room. The context refers to the dynamics of the context. The activities that people are trying to do, the things going on. We can go either with the grain, or against the grain of this context.

3. Fit: Success is judged by the fitness between context and form.

A tendency to focus on form

• There is a tendency towards style based ideologies. A "right way" to do things, based on certain styles & forms.

• We end up making software, buildings, or whatever that follow a standard format without understanding why

• Actually, there isn't one way to design anything. At the same time, not anything goes either

• What matters is the relationship between context and form. The Fit.

• We often see the opposite. In 9 out of 10 times design requirements are expressed in terms of the form.
  Example: "Please can you add a button to change a setting"

• If  design requirements are expressed in terms of form, then success will be measured by that standard. Yes, we've added the button, but was it meaningful?

• On the other hand, if our definition of success is the struggle in a context (something that someone was trying to do, but wasn't able to) we can judge ourselves by the fitness between context and the form.

• We have to fight the tendency to describe things in terms of form. How do we get people to describe the context in a form agnostic way? We want to understand the behaviors that we are trying to enable, independent of the form

• Excellent chapter on this in Notes on the Synthesis of Form  called Goodness of fit

2. What is the outcome we are trying to reach by solving a design problem?

Reference: The Nature of Order, Book one - The phenomenon of life

• Alexander's goal is not to increase sales or to increase efficiency. It's to make a better world

• Christopher Alexander calls this quality "Life"

• Life is not a biological definition. It's the degree to which a certain form enables different types of activities

Example: Soviet style building vs Alexander courtyard

• Look at the ground floor of the Soviet building (left). There's a uniformity of structure.  It's a modular building, designed in isolation of the context. Very little of interest can take place there.

• Compare this with a courtyard (right) by Alexander. There's all kinds of activities that can take place.

• Not a question of style or aesthetics. There's nothing wrong with a modern building

• The difference between these examples is the type of activity that can take place in these buildings

• Inner activity: On a neuro cognitive level, how much does my eye jump around? The courtyard affords a movement of the eye that is much more alive.

• Outer activity: In the courtyard you can take a stroll, take shade, children can play here, gatherings, read a book here, etc.

• This richness of activity in the courtyard comes from the union of form and context

• These kind of activities aren't going to happen in the constricted, blank space in the Soviet style building

• From Alexander's point of view, this planter isn't very alive

• Inner activity: There's not a lot happening that engages the eye

• Outer activity: There's not a lot of activities that can take place on the basis of this form

• If we change the form, we can change the fitness to the context around it. We can make it more alive.

• In the left illustration the edge is narrow. There's not a lot you can do with this (maybe set your coffee down)

• If we widen the ledge (illustration on the right), the form becomes more interesting to look at (inner activity) and it affords something to happen that was desired but not possible before (outer activity)

• There are a lot of activities that might have happened around the previous planter, but couldn't because of it's form. This is not just about being able to sit. Think about different occasions where someone would sit: Someone might be waiting to meet someone. You might arrange to meet someone and sit together. Might be taking a phone-call that you would normally take in a stuffy office, but you can now take outside in the fresh air. You might take a break from shopping. There's a flourishing of possibilities for human experience -for meaningful things to happen- that come out of this change.

• This is the way to think about life. This latter design has more life than the former.

3. What are the processes to get the outcome we want?

• So how do we use this idea of Life in design?

• Alexander gives us tooling to explain what happens in this design process

The two aspects of the design process

1. The static aspect: How do we take a snapshot of the current form? What is the current spatial structure, and how do we describe the geometry and the physical relationships within it? This helps us identify how to get to a better design -a design that is more living- just by looking at the arrangement of things. Alexander calls this the topic of centers

2. The dynamic aspect: How do we improve this form? What do we do in terms of design process to unfold a better design? Let's call this: Generative process. Alexander uses the word generative, and this is important.

1. Centers (the static aspect)

• Main reference for centers is book 1 of The Nature of Order

• All form that exists, whether its a car, a building, a book, or this talk, is comprised of elements (atoms, sound waves, pixels, etc) that exist in a certain relationship to each other

• To our senses, it's all one big world. By partitioning the world of form -by mentally drawing a dotted line- we can identify a unit that we can talk about or modify

• The center explains such a unit of design that in the chain of interdependence drives the others

• It's a way of describing elements that are more coherent and more salient (outstanding)

• Example: In a human face, nature has created an incredible harmony (where all the elements fit together) through step by step adaptation. Even though a face is harmonious, we can still say there some aspects that are more salient. These elements drive the others in the chain of functional dependence. The eyes, nose and mouth stand out as especially salient. These are centers. There are other centers, like the bone that links the eye to the ear, but it's kind of secondary in terms of function. If the eye turns to look, it will follow.

• In nature there is a harmony that has been worked out through a long history of piece-wise adaptation. When we look at build structure however, we don't see the same seamless harmony.

Example: A university campus

• There might be areas with a great deal of harmonious centers: A great entry door to the main building, with a beautiful border around the door, with steps leading up to the door, some landscaping around it. Centers that together create a bigger coherent whole.

• But at the same time, we might wander around the building and find a parking lot, with a dumpster, and some garbage lying around

• Centers give us a way to look at form. They enable us to talk about weak and strong centers.

• Every structure has centers that are more coherent and less coherent. And areas where we would like to create or extend coherence. We do this by improving the relationship between centers.

Personal note: This is important. Ryan talks about how a design is improved by improving the relationship between centers. Improving the relationship between centers creates and extends the coherence of these centers. This will come back later.

2. Generative Process (the dynamic aspect)

Reference: The Nature of Order, Book two - The process of creating life

• The value of pattern languages is different from what most software people think

• This is a map of Rome which shows an amazing network of centers. There are all kinds of individual forms here. Every one of them is beautifully shaped, adapted to the forms around them.

• Inner activity: Aesthetically pleasing

• Outer activity: Functionally, these centers enable all kinds of life to happen

• This kind of harmony can't be thought up. There is too much detail -too much fitness between parts- to have been conceived conceptually by someones brain.

• The way to get to something that is so well adapted is by step-by-step unfolding. By doing 1 thing at a time with careful attention for what is already there. This is step-by-step adaptation.

• Can't talk about step-by-step adaptation, without talking about sequence

• Sequence: The order of problem solving is extremely important. The things we do first, will constrain what what we do next, and what we do next, etc.

• Either this leads us closer and closer to a better result, or it can (step-by-step) paint us into a corner

Personal note: A pattern language is a tool that enables step-by-step adaptation, in the right sequence. We will get into this next.

Pattern languages

• A pattern: A package of form & context

• Some context has been understood. In reaction, some generic arrangement of centers has been designed (a form)

• Anytime we encounter this context, we can solve it with this form and get more life out.

• Example pattern from the book A Pattern Language: If you build a balcony that is less than 6 feet deep, you will find that people don't use it

• There are things that people do on balconies, that are not afforded by a shallow design: Sitting around each other, Stretching out legs, Seting down glasses, plates, newspapers, etc.

• This doesn't tell anything about how to build your balcony, what style or where. It's a specific pattern in relation to a context. This pattern helps you improve the fit from the form to the context. This enables life

• A collection of patterns can be knit together in a pattern language

This is how people traditionally design a kitchen:

1. Take the kitchen floorplan

2. Decide where you want the outer wall

3. Decide how long to make the counter

4. Decide where to put the refrigerator

5. Decide what color to put on the walls

6. Decide what tiles to put on the floor

Personal note: Alexander's says this process is not living: "It will enable people to create virtually any arrangement they wish." This will likely result in a less living design than if we were to constrain our process through a pattern language.

A Pattern language by Alexander for a farmhouse kitchen:

• In this example, windows, the table, the garden or the counter are patterns. They invoke certain forms that fit a certain context.

• A pattern language weaves these patterns together in a sequence. This sequence comes from the natural order to think about things

• In this pattern language we prioritise certain aspects of the form, so that the form can unfold step by step. We're not designing the kitchen in 1 step

• First we figure out the general size and shape, then we place the windows, then we place the table. Why? Because if we sit at the table it's pleasant to have good light.

• And then we're figuring out where the doorway to the garden goes. This is important to do before we place the counters, because the flow of movement between the garden and the table is more important than the exact placement of the counters.

• Lastly, there is a variety of ways that the counters can fill in the remaining space that will be functional. But there are not so many ways that we can place the windows, the garden doors or the kitchen table so that we will have the maximum amount of light.

Personal note: By placing certain patterns in an explicit sequence, and then step by step designing a kitchen in that way, we enable ourselves to unfold the design for a farmhouse kitchen, while keeping into account which elements have higher functional importance. In this way we respect Alexander's idea of generative process, with the outcome of creating more life in our design.

Example: Designing a house and garden

• Most people would place a house first, and then give the garden the leftover space

• The problem: there are fewer configurations where the garden is going to have a good fit -where it's going to be alive. This is because the garden is sensitive to many things: Views, sunlight, the relationship to neighboring properties, etc.

• On the other hand, there are generally more configurations in which the house can be successful

• So if we place the garden first, we can make a fantastic garden. And then there are many ways in which the house can be shaped successfully relative to this garden.

Personal note: Earlier, Ryan referred to how our goal in design is to create more coherence between centers. He refers to that in this example. By first placing the garden, we create coherence between the centers in the garden and the neighboring property. They become more related to each other. This relationship then links the properties, to the garden, and back to the house, creating a more coherent whole. A deep subject that deserves much more attention.

Pattern Languages are project specific

• Rather than saying a pattern language helps us to solve a 1000 buildings, it describes how to go about problem solving for one thing.

• A pattern language explains how we will step by step, solve which problem, in which order, to make this one specific project. It is not a way to be more efficient, and reuse things from the past. But to make 1 thing right, in a way that is fitting, effective, beautiful and enables activities to take place.

• We tend to over-index on the efficiency gains of reusing patterns. Making 1 thing that is whole, functioning and successful is difficult enough.

• A pattern language is what we create, to specify one unique project at the right level of abstraction.

2 benefits of pattern languages

1. A stepwise path through the problem solving process. So that we can step-by-step adapt each center to the neighboring centers, and weave them into a harmonious field of centers that are working together.

2. Allows us to avoid over-specifying details we don't understand in the beginning. We can't draw a masterplan in 1 flash. Why? We don't have all of the centers and interactions between them in our heads. This field of relationships is too complex to have completely in our mind.

Pattern languages enable us to unify design & construction at the right level of abstraction

• A pattern language is a high level way to say what you roughly want, in which order.

• This allows the ones who are actually doing the construction, to go into the level of detail (per step) and figure out the actual form, in the context of doing the building.

• These pattern languages -these handful of words- generate entire classes of different designs

• There are a million possible campus designs that can be generated out of the first pattern language, and there are a million possible campus designs that can come out of the second case

• Were going to get different properties, and different results and a different experience and a different form-context fit depending on the language that we choose

• The fact that there are many ways to implement the design shows that we specified it at the right level of abstraction

• This level of abstraction gives freedom for either our future selves, or other people if we delegate some work, to work out the specific relationships between these things in the context of construction

• The above image is a house that Alexander was building, where they had done some rough sketches for an idea of where to position the fireplace in the kitchen. When they got onto the actual construction site, it was clear this position wasn't quite right

• But because the exact position of the fireplace isn't defined in advance by a CAD drawing. Because the pattern language only fixes the basic field of relationships between the fireplace pattern and the other aspect of the kitchen, and the sequence of problem solving.

• There is freedom in the context of construction and design to do tuning and to make small judgements (that can only be made on the actual site).

• This results in the most successful fit between form and context. The most life.

• Reference: The Battle for the Life and Beauty of the Earth
  A complete case-study for the design and construction for the Eishen school and its use of pattern languages

• Notice (underlined) the different patterns in this language: Inner precinct, Main gate, public yard, Tanoji center, college cloister

• Tanoji Center is a domain specific language. It is a unique pattern designed for this specific project. Main gate could be reused in a different context, but Tanoji Center might never.

• This is the main work of design. To figure out what patterns we are going to define or pull in for this one project.

• By having these key elements of the design we can then generate a great variety of possible solutions.

The 15 properties: types of relationships between centers

1. Boundaries: When we thickened the boundary of the planter, it gave us the better form

2. Levels of scale

3. Contrast

4. Alternating repetition

5. Interlock

6. Roughness

7. Empty space

8. Etc.

Personal note: I'm curious to learn what all the properties are, and how they relate to UI design.

• Purely from the form perspective, it might strike as the Soviet building

• A uniformity of scale, not a lot of interesting structure

• Inner activity: My eyes are kind of glazing over when I look at this.

• Outer activity: There are activities I would like to do that I can't do easily here. Who's really involved with the project here, and what access do they have? If I have questions, who do I ask?

• In terms of relationship of centers, this is not very strong. Like the parking lot & dumpster example before, there is a potential for better structure

• To improve the strength of the centers, we could apply a transformation using 2 of the properties: The levels of scale & Alternating repetition

• If this change is only a structural change, there is no reason to believe it will be better

• Example: Grouping all the people starting with the letter A up to D would not be very informative.

• If there is something from the context motivating this change, we could increase the fitness

• In this case:

1. some people are really involved in a project,

2. others just need to be informed,

3. and then there are other people who are included but don't have anything to contribute

• If we were to segment this screen in these 3 groups, there will be a stronger center at the top of the screen that shows the the people who are most involved.

• Inner activity: This structure is stronger in terms of the form: It's more differentiated, there's more hierarchy, it has a better relatedness between parts, it's more interesting to look at.

• Outer activity: This screen becomes more meaningful. Instead of a purely administrative page, where all I see is a bunch of faces, now I'm better understanding the relationships between people.

• If we would want to build this, a lot of software companies would come up with pixel perfect designs which they would give to their engineers so that they can build what is drawn. Instead we can define this with a pattern language:

• Describing it in a pattern language, gives other people or ourselves the freedom to generate a design that is most fitting, based on the actual facts on the ground that become apparent during the real construction

• If a team at Basecamp would take this on. The team is going to decide on the details of the UI design, and the details of the software implementation on site, in the exact same manner as we saw in the fireplace example

Summary for system designers

• Frame the design problem in terms of form & context. The form is the thing we are making, and the context is the type of activities that take place and the constraints of the situation. This gives us an empirical judgement of fit

• A deeper understanding that this fit is about making the world more full of meaning. Not just doing what the client asked for. We make something that enables life.

• Centers give us a way to talk about key elements of a design, and the relationship between those elements, without talking too specifically about form. It is a high level way of talking about structure

• We get to this coherent structure through a step by step process of unfolding. By specifying the key relationships and the sequence of problem solving at the right level of abstraction using a pattern language. This pattern language is uniquely defined for 1 project, it is not meant to be reused

• We create the necessary freedom at the low level to do step-by-step adaptation, by specifying the pattern language at the right level of abstraction

Q&A

Having read Shapeup, you can see a lot of the motivation

• A lot of this is reflected in Shapeup. What we call shaping at Basecamp is creating a pattern language.

To what extent does the rest of the team at Basecamp actually use Alexander for project planning

• Not at all. Ryan sees it as his task to translate Alexander's work into something specific for Basecamp. He saw resonance between what Alexander was doing, and what Jason and David were already doing intuitively.  So part of it was articulating what they (Jason & David) were already doing, and part of it was building this in a process that we could communicate internally.

• Alexander was an input to this process, but Shapeup is what people at Basecamp read. They don't need to dig to the source

Can computer programs really feel deeply helpful?

• All of us start in a different position, to improve a different corner of the world depending on the skills we have and the network we belong to. If there is any area where someone is struggling, and we can heal that by better understanding the context and putting a better form in place, we will have made the world better. This is always meaningful, at whatever scale we can do it

Does Basecamp have a higher level pattern-language?

• Absolutely. We have something called a "Commentable" in Basecamp, which is a pattern that is foundational. There is an episode in Ryan's podcast "Synthetic a priori" (https://feeds.transistor.fm/synthetic-a-priori) which discusses Basecamp's pattern language

Is there a connection with domain driven development?

• Eric Evans is a fan of Christopher Alexander. His book Domain driven design is a pattern language. But it's a meta pattern language: In the way that the knowledge is communicated is as a bunch of patterns. But Domain Driven Design doesn't explicitly address the notion of defining a pattern language for a software project

• There's a lot of overlap. What Evans calls ubiquitous language, or what he calls modeling is very close to what we deal with when we deal with pattern languages

• Domain Driven Development is probably the best resource for a software person who wants to think about their design as a pattern language

What order of Christopher Alexander's books is best for software designers?

• Read the first 2 chapters of Notes on the synthesis of form to get comfortable with form context & fit

• Then get into Battle, as an example of a pattern language, and see how an actual project was build using it There's a lot of stuff about the struggle of building things the Alexander way, you can skip those if you are only interested in pattern languages

• To go deep, read the nature of order which is the definitive reference, but very dense

• If you are a software developer that wants to apply these ideas, Ryan recommends reading Shapeup which embodies a lot of these things

Can you speak about the relationship between Jobs to be Done and how it helps to produce a pattern languages?

• JTBD is about defining context in such a way that you can have a proper empirical judge of fit

• It's a way to understand demand, that is supply agnostic. This is the same as saying "how do we understand the context in a way that is form agnostic".

• Demand side is the context, the supply side is the form. Understanding the context gives you the activities that people are struggling with. And now the question is; How do I transform the form to improve the fit to the context?

• We produce a pattern language from this, by taking our understanding of the context and the patterns that we already know

• Clayton Christensen has a subject called modularity versus interdependence. What do we build custom, and what do we pull off the shelf? This idea maps to patterns that are available from prior work, and patterns that you have to invent on a per project basis. The Commentable in Basecamp is a project specific pattern, just like the Tanoji Center is specific to the Eishen school project. But main gate, and push notification are not specific patterns to a project.

• So we have patterns that we can reuse and combine into a pattern language to try and improve the fit, and then we might have gaps where we have to define patterns for this specific project.

Anything Christopher Alexander advocates for that you disagree with in the books you mentioned?

• Looked very hard, and haven't found anything

• Impressed by depth, and universality of his work

In terms of sequence or process, how do you know you are on the right path?

• The sequence has to do with which things are most important, which things have the fewest degrees of freedom in terms of the possible designs that are going to work

• Like the house & the garden example. If there's fewer ways the garden can be successful than the house, you have an asymmetry and a dependence between them. Anytime you have an asymmetry in terms of the criticality of the component, and you also have a dependence on other components, this gives you the sequence. Through a 2-dimensional analysis of what are the dependencies, and how constrained is the space of solutions for those. Out of that you can kind of get a structure analytically that will guide you to the right sequence

Do you distinguish between patterns & reusable components?

• It's a pattern if the component is not only in terms of form, but it also has some understanding of context attached to it

How do you read books and understand so deeply?

• By spending a lot of time, thinking hard, and questioning it

• By first trying to understand what are they saying, then considering if I can actually apply it to what I'm doing, then struggling to apply it, and then allowing time to go by, then going back and trying again, etc.

Have you seen Alexander's 15 properties map to properties in the software world?

• I think I demonstrated that with the design example I gave in Basecamp where we used levels of scale and alternating repetition

• Another example: Levels of scale applies within code. Look at Kent Beck's composed method in Smalltalk best practice patterns

In software how do you see the role of Product strategist, managers, designers and engineers?

• Detailed in Shapeup

• There is a role in Software desigs figuring out what the pattern language is

• And there is a role how do we use that language to generate a design at the lower level

• This might be done by the same person

• Generally speaking, the front-end engineer and visual designers focus on the specifics of UI design down to the pixel and the implementation of methods in the code

• What we call shaping is the pattern language level. Demand side research, or trying to arrive what projects should we build, corresponds to trying to understand the context

How does this work not apply when designing for new business ventures?

• There's no difference. If I'm making something, I need to understand contex, in order to achieve fit

Can you say something about pattern vs form?

• A form language is lacking context, it's on the stylistic level

• While a pattern language is about the union between form & context

Any projects or orgs put Christopher Alexander in practice well?

• Bob Moesta's work  at the Rewired group maps 100% to all of this

• There are architects using this

• There's a growing amount of companies implementing Shapeup, and in doing so unknowingly implementing Alexanders practices. Shaping creates the autonomy which is the same as Alexanders Generative process

How can a software engineer start applying these concepts?

• It's a question whether or not the thing we make is maximally useful in the context where it appears

How do you evaluate fit at the different levels of abstraction?

• The place to think about fit, is not across different levels of abstraction.

• The levels of abstraction are about the generative process

• The fit comes from where the rubber meets the road, the concrete level. Like the real physical balcony that's too small and the context of people wanting to do things on it.

• Imagine we want to extend this balcony to make it bigger we are going to go from a struggle (a lack of fit at a concrete level) and say"what can we do to improve that?"

• Now we have a problem, because we have to coordinate a whole bunch of actions, and enable a lot of small decisions to get to the part where we have a new design that works better. So we go up to the abstract level of the pattern language to try and specify what we think we can do in terms of the main relationships between centers, the main activities that we can to achieve, the fit we want.

• From that we generate a possible solution at the concrete level. Then we can judge if it achieves the fit we want.

• We make this arc: Concrete -> Abstract -> Concrete.

• This is why you see many fantastic examples in book 2 (The Nature of Order) of Alexander using cardboard to mockup the position of walls, fireplace, etc. Because they know they need to determine the fit at the concrete level.

• At the abstract level there's no tradeoffs. But at the concrete level we are going to run out of time. We are going to bump into the reality of things. The concrete is the level where we look to find fit.

Imagine trying to sell The Mirror of the Self Test to clients

• This is a reference to a concept in The Nature of Order – Book 1

• This is the wrong level of abstraction.

• Clients are not hiring us to improve the world. They are hiring us to eliminate a local struggle that they have to themselves

• We can use this Mirror of the Self Test on ourselves as a guide.

• but this is on the way to fulfilling the bigger contextual struggle the client has

Acknowledgements & Resources

Ryan Singer for his Primer on Christopher Alexander

Ryan Singer deserves credit for his introduction to Alexander's work. He has managed to remake a dense topic into something exciting and fun. You can read and subscribe to Ryan's newsletter here

Christopher Alexander's work referenced (in order)

1. Notes on the Synthesis of Form
   The important thing is what you get in the first 2 chapters (good primitives). Don't need to read the rest.

2. The Nature of Order, Book one - The phenomenon of life

3. The Nature of Order, Book two - The process of creating life
   If there is one book to read: This is the one.

4. The Battle for the Life and Beauty of the Earth
   In depth case study of a project

In my previous post on the struggle of being a PM I showed that in most organisations Product Management is broken.

The top 2 problems that PMs experience?

1. 🏭  A lack of influence over the product strategy. In a Feature factory.

2. 😓 Overwhelmed by competing and shifting priorities.

Research showed these problems are industry-wide and frustrating.
PMs are eager to solve them but don't know how.

In this second part I attack these problems by creating a contrast between the Overwhelmed PM and the Focused PM. This contrast reveals that the Focused PM doesn't work more hours, but they apply their time more effectively. They do this by leveling up. Leveling up is probably the most important concept in product.
It explains how to create focus & deliver breakthrough innovation by seeing the bigger picture. And I'm about to explain it to you.

Overwhelmed PM versus Focused PM

Imagine two PMs at opposite ends of the spectrum:
The Overwhelmed PM versus the Focused PM.

The Overwhelmed PM has the problems from our research.
These PMs feel they lack influence on the product strategy. Managing feature requests from a visionary CEO or  sales is a constant struggle. They are stressed and overwhelmed by competing and shifting priorities.

The Focused PM makes the job look easy. They are calm, confident, and focused on the things that matter. They solve their problems with style and a smile on their face. They make an exceptional impact by building products people love.

So what sets these PMs apart? Does the Focused PM work harder? Is it a matter of throwing more hours down the pit? Hint: It's not. The PMs I coach often work extra hours (and sometimes weekends) and are still overwhelmed. So if more time isn't the answer, then what is?

The Focused PM applies their energy in a different place.
If the Overwhelmed PM scatters their energy like a flashlight in the dark, the Focused PM points it like a laser.  The Focused PM makes decisions that enable them to focus.  It's no coincidence that the verb decide comes from the ancient Latin decidere. which translates to "cut off". Because to cut off options, is the essence of focus.

Let's break it down.

Juggling too many ideas

This is what the typical PM encounters on the job.

Raw ideas flow in from different sources and stakeholders. Some ideas seem more urgent than others, but it's hard to tell without investigation. Most PMs dutifully write them down. With a reassuring nod, they speak the words, "It's in the backlog". Yet these are words of false comfort and leave the PM with a guilty taste. Deep inside, they know the backlog is where ideas get lost.

Some PMs try to juggle all these ideas.
To create a sense of order, they use ranking algorithms (like RICE).

But as the backlog grows, even the most persistent PM's realize it's futile.
Nobody can keep these ideas in their head, let alone investigate and rank them.

This is when backlog bankruptcy is declared. The slate is wiped clean.
Only for the same Sisyphean ordeal to begin all over again.

It's not a surprise many PMs feel overwhelmed. Nobody can juggle 100 balls, not even the world record holder (16 balls, I looked it up).
Which can we drop?

Leveling up

The first step is to realize ideas come in different types:

• Opportunity: Unsolved problem, or unmet need.

• Solution: Feature idea or request.

These types have a relationship: A solution is a response to an opportunity.
Example: If "wanting to drill a hole" is the opportunity, then "a drill bit" might be a solution.

This relationship is not optional. A solution without an opportunity is like making a random key and hoping it will fit a lock. It doesn't make sense.

Even though solutions without an opportunity make no sense, they are common in practice.

We, our users or colleagues come up with features all the time. This is normal. It is human to think in solutions. But we have to take these suggestions with a grain of salt. People are not good at predicting their own behavior.

“It’s not the customer’s job to know what they want.”  
- Steve Jobs

Our job as innovators is to figure out the opportunity, the motivation, behind feature requests and then invent on behalf of the user. This isn't because users aren't smart. They simply don't have access to the knowledge, skills or resources to innovate effectively.

It boils down to this: you aren’t allowed to tell them what their problem is, and in return, they aren’t allowed to tell you what to build. They own the problem, you own the solution.
Rob Fitzpatrick - The Mom Test

To figure out the opportunity behind a feature request we take a step back and ask "why?". This enables us to level up to a bigger context. Level up by asking "why?".  

If we ask why to a proposed solution we discover the opportunity. Based on this opportunity, we can invent new solutions and group feature requests. This forms the beginning of a tree structure:

Leveling up doesn't stop here.
Keep asking why to level up to an even bigger context.
Conversely, ask how to level down.

The higher we climb, the more aspirational the opportunities become (to the point of getting metaphysical).

Leveling up too many times on the bigger context can quickly get meta-physical quickly where you start questioning the meaning of life. But most innovators don’t level up at all.
- Ash Maurya

So where do we stop our inquiry?

The Customer Job

We continue asking why until the opportunity that we reach is an end rather than a means. A real goal instead of an intermediary goal:

Harvard professor Theodore Levitt once pointed out, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”

However, Levitt’s implication that the goal is really a hole is only partially correct. When people go to a store to buy a drill, that is not their real goal. But why would anyone want a quarter-inch hole? Clearly that is an intermediate goal. Perhaps they wanted to hang shelves on the wall.
Levitt stopped too soon.

Once you realize that they don’t really want the drill, you realize that perhaps they don’t really want the hole either: they want to install their bookshelves. Why not develop methods that don’t require holes? Or perhaps books that don’t require bookshelves. (Yes, I know: electronic books, e-books.)

Don Norman - The design of everyday things

Such a real goal is called a Job To Be Done (or a Customer Job). A Customer Job is the progress that a consumer wants to make in their life:

A Job to be Done is the process a consumer goes through whenever she aims to transform her existing life-situation into a preferred one, but cannot because there are constraints that stop her.

Alan Klement - When Coffee Meets Kale

The illustration below shows the difference between a Customer Job (on the left), and intermediary (functional) goals on the right.

Sure, the material used for the wheels matters (intermediary & functional goal), but only so much as it helps the user be impressive on their skateboard (the Customer Job). The Customer Job is what users evaluate your product against. It is their yardstick. This is why we level up until the Customer Job. Any innovator that wants to make something of value should understand this.

A comparison to Toyota's five why technique

This analysis is strikingly similar to Toyota's five why technique:

The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question "Why?". Each answer forms the basis of the next question. The "five" in the name derives from an anecdotal observation on the number of iterations needed to resolve the problem.

The technique was originally developed by Sakichi Toyoda in the early 1900s and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies.
Five why's - Wikipedia

There are 2 things we can learn from the five why technique:

1. Asking why should be with "Gemba attitude"

2. A product can serve multiple Customer Jobs

Let's get into it.

1.  Asking why should be with "Gemba attitude"

Both Jobs To Be Done Theory as well as Toyota's five why technique, emphasize doing the analysis at the place where the problem occurs. We can't just ask "why" a couple of times and speculate about the problem. We should talk with the user to find out. At Toyota this principle is called "Genchi Genbutsu" which literally translates to "real location, real thing”.

Taiichi Ohno, creator of the Toyota Production System is credited, perhaps apocryphally, with taking new graduates to the shopfloor and drawing a chalk circle on the floor. The graduate would be told to stand in the circle, observe and note what he saw. When Ohno returned he would check; if the graduate had not seen enough he would be asked to keep observing. Ohno was trying to imprint upon his future engineers that the only way to truly understand what happens on the shop floor was to go there. It was where the value was added and waste could be observed.

Genchi Genbutsu is, therefore, a key approach in problem-solving. If the problem exists on the shop floor then it needs to be understood and solved at the shop floor.

Genchi Genbutsu is also called Gemba attitude. Gemba is the Japanese term for "the place" in this case "the place where it actually happens".

Wikipedia - Genchi Genbutsu

So when you ask "why" to level up, it should be by talking with users (with Gemba attitude). At the end of this article, I share my favorite resources that explain how to interview users and discover Customer Jobs.

2. A product can serve multiple Customer Jobs

One of the criticisms on Toyota's five why technique is:

"A tendency to isolate a single root cause, whereas each question could elicit many different root causes."

Let's avoid this mistake by being clear: A product can fulfill more than one Customer Job.  There can be multiple Customer Jobs at the root of our tree:

It's like how plants grow conjoined if their tissue is touching (this is called inosculation).

This is not uncommon. Products often have multiple usecases without the designers being aware of them. A personal example that involves a "Pee Watch":

I'm a father of two young children. The only time I get any writing done is early in the morning, so I set the alarm on my phone. However, my wife wakes up at the sound of this alarm and can't fall asleep anymore.
So what to do?

After browsing a while, I found a wristband that buzzes my wrist at a predetermined time. Ideal for my Customer Job. I get to wake up, and she doesn't. The funny part? These watches are meant for children or the elderly to remind them to pee or take their medicine. They are literally called "Pee Watches" on the Dutch website.

I'm pretty sure the designers of these watches have no idea their product is used for a Customer Job so different from what they imagined. I guess there are more parents that want to rise early without waking their partner. Could this product tap a whole new market if focused specifically on this Customer Job?

This shows that features that are designed for one Customer Job, can (un)intentionally serve another. In the case above, the buzzing alarm functionality serves my Customer job of helping me find time for creative expression. Some of the other features like the ability to set 7 alarms throughout the day complicate the watch interface for me. They are essential for letting a child know when to pee, but I don't need them for my Job:

Companies often aim to increase their reach by serving more Customer Jobs with the same product. The illustration above shows why this is risky. With more features the product becomes less specifically attuned to each Customer Job.
Like a swiss knife, they become OK at everything but great at nothing.

This is how many startups beat incumbents. They unbundle a Customer Job that isn't served specifically enough. Rather than a swiss knife, they forge a sword that cuts to the essence of what a customer wants to get done. As an example: In a recent article, Greg Isenberg explains how to unbundle a Reddit community:

... each community has to conform to the one-size-fits-all mold of a subreddit. One size fits all, but it doesn't fit anyone particularly well. That creates unbundling opportunities.

There are hundreds of wonderful startups waiting to be built using this simple strategy: create a product that serves the unmet needs of an individual subreddit.

Greg Isenberg - The Ultimate Guide to Unbundling Reddit

Does your product serve more than one Customer Job? Think carefully about each Job that you serve. Consider if a Customer Job wouldn't be better off in a separate product. Alternatively, you could drop Customer Jobs to increase the focus of your product.

The Jobs Tree

Voila! Out of a mess of raw ideas, a tree structure has emerged.
I call this a Jobs Tree (after Jobs To Be Done theory). This Jobs Tree is likely to have multiple Customer Jobs at the top which are revealed by talking with users.

This Jobs tree is strikingly similar to William Powers’ hierarchy of goals where the Principals are like our Customer Jobs:

"William Powers’ hierarchy of goals is a widely accepted model of the relationship between the things we do, and why we do them."
Alan Klement - When Coffee and Kale compete

Powers' hierarchy illustrates how the higher we level up, the more aspirational our goals become, with the Ideal self at the top (or root) of the tree:

"Your ideal self is a synthesis of various Principles or “Be” goals. For example, you think of yourself as a particular type of parent or friend and having a particular set of personal freedoms. These Be goals are what motivate you to choose and carry out one or more Programs or “Do” goals. These Do goals are then fulfilled by Sequences or Motor control goals"
Alan Klement - When Coffee and Kale compete

Besides giving the Jobs Tree credibility, Power's hierarchy confirms that leveling up to "Be" goals (or Customer Jobs) helps to understand the motivation behind functional (Motor control) goals. This further shows that leveling up is key for any innovator. But how key really? What is the power of leveling up?

The power of leveling up

Leveling up gives three advantages:

1. Create focus by enabling strategic decisions

2. Deliver breakthrough innovation by seeing the bigger picture

3. Establish a stable foundation by researching the timeless

Let's break it down.

1. Create focus by enabling strategic decisions

When we have to decide on a course of action, the Jobs Tree enables us to make strategic choices before diving into the details. This starts at the Customer Job level. First, we choose a Job to focus on:

Can you see how this reduces scope? We just cut off an entire branch of concerns. Next step: which opportunity under this Customer Job can we prioritise?

And this goes on. Like a traveler that makes a turn at each crossroads, we decide every level we go down. Which of the opportunities serve the Customer Job and the business best? And after that?

In moving from the top to the bottom, we progress from the strategic to the functional. The higher we level up, the broader the strokes of our brush. Like how an artist paints the large areas of the canvas before its details, we optimize for the global maximum before doing so locally. We decide. That's the essence focus.

Note: This explains why the top 2 problems (at the beginning of this article) PMs face are two sides of the same coin. When PM's feel they lack 1. Influence they can't apply focus to the product strategy (at the root of the tree). As a result, they need to consider all possible branches, and this is 2.Overwhelming.

2. Deliver breakthrough innovation by seeing the bigger picture

Most never rise above the functional. Only by leveling up to the Customer Job do we learn what customers really want. And this is essential:

"You’ve got to start with the customer experience and work backwards to the technology. You can’t start with the technology then try to figure out where to sell it."

Steve Jobs - 1997 Apple WDC

The bigger the context that we solve the more value we create for users.
Power's hierarchy reflects this:

Be goals have the highest priority; Motor control goals have the lowest. Be goals are the core drivers of all our actions and decisions. This also means that, no matter how well a Do or Motor Control goal is fulfilled, it’s a failure if the higher Be goal is not satisfied. It also means that a Do goal doesn’t have to be successfully executed to fulfill a Be goal.

So we should always measure the progress we make on the Customer Job.
It's the only thing users care about.

Upgrade your user, not your product. Don’t build better cameras—build better photographers.

—Kathy Sierra

So how does this look in practice? These examples copied from Ash Maurya's article on Job-To-Be-Done, show how you could approach innovation differently when leveling up.

• If you are a drill manufacturer, you might be inclined to focus on building better drill bits that don’t break:

• If you are 3M, you might build strong mounting tape that eliminates the need for drilling altogether:

• If you are Samsung, you might sell more flatscreen displays that replace artwork on walls:

Pretty cool right? Rather than staying stuck in the mud of the functional, leveling up helps us see the bigger picture, so that we address Customer Job in novel ways.
This is the key to breakthrough innovation.

3. Establish a stable foundation by researching the timeless

The closer to the root of the Jobs tree, the more stable our opportunities are.
It's like how the wind shakes the branches of a tree, but merely grazes the stem.  
A feature can change overnight, but a Job remains stable for thousands of years.

Example: "Expressing yourself through art" is as old as mankind, but drilling a hole in the wall can be replaced by a new solution any moment.

Power's hierarchy of goals reflects this:

Be goals are the most stable; Do and Motor control goals are transitory. Be goals are states of self-perception. They are entirely emotional (or psychological if you prefer that word). Do and Motor control goals are purely functional and are technology dependent. They are things you do to fulfill a Be goal. Stated another way: You don’t ultimately want to achieve the Do and Motor goals; you want the Be goals.

Alan Klement - When Coffee competes with Kale

This shows research higher in the tree is more timeless. By leveling up, we establish a foundation that lasts. Knowledge about Customer Jobs is a bedrock on which we can build our castle.

Leveling up: Our ladder to the stars

At the start of this article, we aimed to discover the difference between the Overwhelmed PM and the Focused PM. We learned it's not a difference of energy, it's where this energy is applied. Where the Overwhelmed PM considers all ideas, The Focused PM levels up to the bigger context.

We visualised leveling up with the Jobs Tree. We learned that the Jobs Tree can have multiple Customer Jobs at the root and these are uncovered (with Gemba attitude) by talking with users .

Leveling up is powerful because it enables us to:

1. Create focus by enabling strategic decisions

2. Deliver breakthrough innovation by seeing the bigger picture

3. Establish a stable foundation by researching the timeless

That's it. Leveling up. Arguably, the most important concept in product.
The thread that binds great innovators across the ages.
The wings that elevate our craft into a form of art. Where the sculptor chisels away marble to uncover a statue, we ask "why?" to discover the Customer Job.

"Every block of stone has a statue inside it and it is the task of the sculptor to discover it.”
- Michelangelo

To me, this makes leveling up not just a powerful concept,
it is our ladder to the stars.

And you have your choices
And these are what make man great
His ladder to the stars
Mumford & Sons - Timshel

Acknowledgements & Resources

Opportunity Solution Tree - Teresa Torres

The Jobs Tree is partly inspired by Teresa Torres' Opportunity Solution Tree (OST). I owe a lot of credit to her work. I recommend subscribing to Product Talk, and getting her upcoming book (which I'm sure will be excellent).

Key differences between the OST and the Jobs tree:

1. The OST has a "Desired Outcome" at the top.
   The desired outcome in the OST is a measurable outcome, that combines business and user goals (like OKRs). This desired outcome will act as a sort of filter for the opportunities below. The Jobs  Tree on the other hand always has the Customer Jobs at its root. It's a pure reflection of the hierarchy of user goals, and nothing else. I feel many organizations focus too much on things other than a qualitative understanding of the customer, so I wanted to keep the Jobs tree purely about the Customer, and nothing else.

2. The Jobs Tree integrates JTBD explicitly as a core principle

Recommended Jobs To Be Done resources:

• When Coffee and Kale compete - Alan Klement

• Competing against Luck - Clayton Christensen

• Demand-Side sales 101 - Bob Moesta

• The Mom Test - Rob Fitzpatrick

• Keep digging - Ryan Singer

• What is a Job-To-Be-Done - Ash Maurya

1. 🏭 In a feature factory. Sales or a visionary CEO are pushing solutions. PM's feel like Project Managers with little influence on the product strategy. They have difficulty changing the organisation to a product mindset.

2. 😓 Overwhelmed by competing and shifting priorities. PM's don't know what to focus on and have a hard time balancing it all. They feel like they have to fight fires constantly.

Recognize these? You are not alone.

The Struggle of being a PM

Skim the PM communities and comments like these are typical:

"I am a solo pm at a midsized company and I am drowning in responsibilities. From time to time I get anxiety about my performance not being good enough [....] The areas that are suffering are the vision and product strategy. [...] The pressure from the organization feels like I need to spend more time in those areas but I am having a hard time balancing it all."

Sounds pretty bad right? Recently I started wondering. How widespread are these issues? Why are they so persistent? Are they part of the job, or can we fix them?

I started logging every comment expressing a pain or a desire:

When I was satisfied with the amount of samples, I categorized them.
This is what I found:

Top 2 Pains:
1. A lack of influence over the product strategy. In a Feature factory. (40%)
2. Overwhelmed by competing and shifting priorities (24%)

This investigation confirmed a hunch. Many PM's struggle with a lack of influence over product strategy.

It's not surprising that this cartoon is a top post on the Product management Reddit:

Industry Research

Do these findings reflect what is going on in the industry at large? A recent survey by Product Management Festival (2020) under 2000+ product professionals, seems to indicate so.

It looks like Lack of executive support and Not being able to influence management map pretty well to our top pain 1. A lack of influence over the product strategy. Competing objectives and Lack of time fit well with our second pain of being 2. Overwhelmed by competing and shifting priorities.

In a report by Feedback Loop (2020) the top wish was a clearer product strategy:

This shows PM's see the importance of a clear product strategy,
but lack the influence to realize it.

Digging deeper

Having established these problems are widespread, I wanted to dig deeper.
How critical are these problems? What is their impact? To answer these questions, I decided to offer myself as a coach for PM's on Reddit, hoping I would find traction by using the keywords from my research:

I did not expect what happened next. Within a week I received 57 coaching requests! This was great but also terrifying. I have a dayjob and these sessions would be done after-hours. Fortunately, with permission from the participants, I was able to share the load with the venerable @uxdesigntom (thanks Tom)!

The variety of PM's that signed up was broad except for a bias to the inexperienced side. Does this mean it's mostly inexperienced PM's that suffer from these problems? I also guess few people are interested in getting coached by someone with less experience.

To understand how critical the problems these PM's experience are I asked:

On a scale of 1 to 10 where 1 is not very important and 10 is very important, how important is it for you to solve your struggle?

The average of all of the 59 coaching requests, was a whopping 9.1 out of 10.
This wasn't proof yet the problems are critical, but it sure seemed like it.

Coaching sessions

In the weeks that followed, I coached 19 PM's across the globe (from California to Singapore). This was fun. I was grateful for the opportunity to talk to so many different people about the craft I love. But however diverse my coachees, their issues were similar. It confirmed my earlier research.
Most PM's suffer from 1. A lack of influence on the product and are
2. Overwhelmed by competing and shifting priorities.
Let's go down the rabbit hole.

1. A lack of influence on the product

PM's are sold on the vision of the Product Manager as the CEO of the product. They expect to get a central role in defining the product strategy and this is what attracts them to the job. But the ideal that they read about in books doesn't match up with how it works in practice.

When asked about this ideal, they would invariably give me a regretful laugh.

"Yeah, that's not how it works for me. I loved reading "Inspired", but it also makes my issues seem insurmountable."

Instead, they found themselves in an organisation lacking the "Product-Mindset". Rather than being managed by outcomes (like the ideal prescribes), they are managed on outputs. A true feature factory. More than once I heard a mention of either an ideas CEO or sales forcing solutions on them. They feel out of the loop of the decision making process. They lack influence on the product strategy. In a recent Tweet, Ryan Singer (Product Strategist at Basecamp) points to the same uncomfortable truth:

In reality very few Product Managers actually decide what to do. It's coming down to them from a stakeholder.
- Ryan Singer

The PM's I spoke to believe the solutions that get pushed are often devised without an understanding of the customer.

"The bigger customers dominate what gets built. We do it because we're afraid of them churning. When we do it, the customer doesn't churn but the features aren't actually used."

On top of this, priorities are also constantly shifting. New solutions are pushed, before the previous are seen to completion. Management is seen as reactive.
There is a lack of focus. A missing committment to the long-term. Multiple PM's unpromptedly coined the term Shiny Object Syndrome to me.

"Executive “shiny object” syndrome where new projects continue to interrupt and disrupt the objectives we’ve mapped out for the half. The lack of focus makes product discovery difficult and the team is spread thin across multiple contexts. Many of our features never reach their true potential due to a lack of iteration — when a project is launched we have to move on to the next."

So what's left when you remove the influence over the product from a Product Manager? A Project Manager. A mercenary, not a missionary:

"Teams of missionaries are engaged, motivated, have a deep understanding of the business context, and tangible empathy for the customer. Teams of mercenaries feel no real sense of empowerment or accountability, no passion for the problem to be solved, and little real connection with the actual users and customers."
- Marty Cagan

The description above by Cagan fits this quote by one of the PM's I spoke to pretty well:

"My understanding is (that the role of a PM is ) to create the context for teams to succeed and collaborate. But now I'm managing timelines for products that are planned. I end up doing a lot of project management work."

Definitely not what they signed up for.

2. Overwhelmed by competing and shifting priorities

This solution oriented and reactive environment has some serious consequences.
It becomes difficult shipping things.

"It's very frustrating. It feels like we're not getting anything done."

To the credit of the PM's I interviewed, they are not looking to change jobs, but are passionate about making it work. More than anything they feel loyalty and responsibility to their teams. They worry about dissatisfaction under engineers and designers.

"I worry about hiring more, because someones whos good at their job will quit. The engineering team is frustrated. I'm frustrated. I believe it can work, but it's not coming to fruition like this."

They also worry about their own career. How can they grow, if all they do is Project management, and not Product management?

"For my career growth, I need to get experience in shipping stuff. But when initiatives get halted like this, I'm not [...getting the experience]"

And this is impacting their confidence:

"Makes me feel uncomfortable, is the org too large? Am I doing it wrong?"

When I told them these problems are common, they would sigh with relief.

"I'm really happy to hear I'm not the only one. At least I'm not alone."

The goal is clear, the road is foggy

It's not a lack of trying. These PM's read books, follow courses, setup strategy meetings, push for OKR's, and much more. Booking this coaching session was just their latest attempt to crack the problem.

This drive comes from their vision of what great looks like.When I asked them about their idea of success, their faces would light up.

"Finally, the team will be calm. We are achieving an impact.We are confident in our ability. We have an influence on the product strategy. And I'm less frustrated."

For many where they want to go is clear.
It's just the road that is foggy.

The root of the problem

Analyzing the PM communities I found 2 problems that keep coming back:

1. A lack of influence over the product strategy

2. Overwhelmed by competing and shifting priorities

These problems are frustrating and persistent. PM's try many things to fix these issues. They know where they want to go, but just not how to get there.
So let's figure it out!

In the next part I will attempt to crack this puzzle, by digging deeper into the root of these problems.  I will show that a 1. lack of influence is the cause of PM's being 2. overwhelmed.