Please join me there if you’re interested.
Here is the note explaining the shift:
In 2020, I am looking to write about cross-functional product development more regularly and intentionally. In the past, I have struggled with the following:
Being short on time — and looking for immediate gratification — my habit has been to publish whenever/wherever, and just hope people will notice. I was reviewing Twitter recently and noticed halfway decent threads posted at 2AM while I waited for Julian (my son) to wake up and feed. This is worrisome on a couple levels: 1) I should be sleeping, and 2) I’m probably missing people I’d like to share and collaborate with. …
These notes are based off of the v 1.7, 2019 edition of Shape Up. They may introduce new versions at which point the page numbers will not line up.
I wrote this after having a number of people ask me about Shape Up. It is in bullet and notes form. Basecamp is doing something right, because this has come up in conversation multiple times.
Apologies for slowing down my writing output! I’ve been busy the last couple months co-writing, editing, and producing a book on the North Star Framework for Amplitude Analytics (my day job). Luckily the book heavily overlaps most of my interests, and I was even able to include some prior drawings and explainer videos. I wouldn’t say it is the penultimate “John Book”, but it was a huge learning experience and I loved working with a team on something (not to mention a big group of 50+ reviewers).
What is the North Star Framework? Nothing groundbreaking…but surprisingly effective (especially at triggering the right conversations). …
How do product managers lose the trust of their team?
How they communicate with their teammates plays a big role.
A product manager says “I think we should stop iterating on this feature.”
The designer and engineers on the team disagree. They’ve been reviewing some customer feedback, and they’re not very proud of this work. In their opinion, the interface needs usability tweaks and there’s some refactoring left to do.
So they let the product manager know about their concerns.
Let’s imagine four sample responses from the product manager:
So! You have arrived at this post for the definitive MVP definition. The definition to rule them all. An answer to your pent up MVP angst. The “I TOLD YOU SO!” fodder for your Slack #product-articles cannon.
I am here to disappoint you. Here’s the deal. You need to have a conversation with your team. This is one of those things where five people can read the same article and walk away with very different definitions. Experience is everything. After thousands of posts, talks, and books, we aren’t getting closer. We may be getting further away.
So you need a new tactic. A conversation. …
So you want to fix something in your company? You’re not happy, and want something to change? Here is a quick thread describing I was given once, and ignored. And paid the price. And now I give it to others.
Keep in mind the sad, sad fact that folks stuck in a system — even when they know how to fix it, and have been preaching change for a long time — are often too bitter and disillusioned to influence change. You have to avoid that. Don’t let things fester that long.
It is helpful to not get associated with a particular idea or method or solution. You’ll be immediately put in a box. If you’re going to advocate for something, advocate for building the continuous improvement muscle. …
An organization has many “product teams”, but the teams lack autonomy, the work is riddled with cross-team dependencies, and the teams share team members (e.g. product, design, data science, and ops).
Rewind, and you often find a well-meaning attempt to support small teams…and a manager who was having difficulty reigning in the mess, and wanted to have a smaller number of people report to them.
We just can’t have meetings this big!
The org optimizes around this new structure. People are hired to support and manage it. Team members are hired to join X team. You start to see team-level roadmaps/backlogs. Now, small teams ARE good, they are, but the org wasn’t ready to support these teams, and in many cases the key driver was efficiency and cleaner meetings, not efficacy, customer value, and team autonomy. …
One of the thorny challenges when attempting to improve a system optimized for high WIP, is that it is almost never as simple as “visualize work and lower WIP!” Nor is it always about factors external to the team. Expect deep, and seemingly irrational resistance. Why? Consider what the system is currently optimized for:
I frequently meet teams struggling with OKRs.
When I dig deeper, I often find that the team is having to “reinvent the wheel” each and every quarter. There’s a mad rush in the final days of the quarter to fine-tune objectives, “come up with” key results, and make sure it all “ties together up and down the organization” (while simultaneously doing actual work). In short: painful and disruptive, or as an engineering manager once described to me “planning masochism”.
The culprit is that teams are often trying to dream up results for “projects” instead of forecasting their impact on longer-standing missions, or they are part of an elaborate multi-leveled “cascade” of quarterly goals. Both of these patterns are a result of treating quarters as lengthy organizational delivery sprints vs. a cadence of introspection. …
I was chatting with a team recently and an engineer said something that really made me happy:
We know something is working when we spend longer on it, instead of shorter.
Her team was delivering into production daily/weekly. They could have easily bragged about how “quickly” they “move things to done”. But she didn’t. Instead, the engineer pointed out that when they’re in the groove, learning quickly, and having an impact, they tend to keep working instead of just jumping to the next thing. The “it” in “spend longer on it” was not a feature or project. …