thoughts and inspiration on designing, programming, and writing for the web
In a project management-themed Hackers Incorporated episode, Adam Wathan introduced derisking projects with save points. The entire episode is definitely worth your time, but that specific piece of advice has changed the way I work as a developer and make decisions as a project manager.
In practice, it has taught me to optimize for optionality, not efficiency.
An interesting thought exercise on working together, what's the optimal number of people to work as a team without spoiling the broth?
Let’s say you have 100 people. They can break into groups of any size. Each group gets 100 toothpicks. The goal: build the tallest structure with the toothpicks. What is the optimal group size?
16 Nov 2023 via thunk.dev
John Drexler shares an easy to implement prioritization scheme when working with a client.
It's a gift when another team gives you a wishlist of product improvements. Ask them to put their lists in order of importance, and then focus the conversation just on the top 5. This saves you loads of time. But it also brings them into the prioritization discussion and gets them to think like Product Managers too.
A little Sketchplanation on "point positive".
Point positive is a rafting term for agreeing in advance to point towards the safe way out of danger rather than towards the dangers themselves.
When you're in trouble, don't dwell on the cause, look for a solution. Only when the waters are calm, take a step back, reassess, and learn the necessary lessons to avoid it in the future.
Apparently Frank Herbert's Dune can teach us lessons on product management:
Arrakis teaches the attitude of the knife - chopping off what's incomplete and saying: "Now, it's complete because it's ended here."
(I haven't read the book yet, but would love to one day!)
When you define too much work up front, you add unnecessary management overhead. More importantly, you create a bias and stifle a team's creativity to solve the problem.
No one defines all the work up front. That's a fools errand. Assuming you know too much up front is the best way to find out you're wrong in the end. Instead we define the direction, the purpose, the reason, and a few specific "must haves" up front. The rest — all the rest, which is mostly everything — is determined during the project, by the people on the project.
Ryan Singer talked about how they (don't) deal with roadmaps on the Signal v. Noise blog.
In short: roadmaps are a bad idea because they can create uncertainty, false expectations, and guilt. My favorite argument against long term roadmaps is the uncertainty.
We don’t have a crystal ball. Say we have features A, B, and C we want to build. We don’t know if A is going to work out as planned, and what that would mean for B. We don’t know if we’ll have a eureka in the bathtub one day, and new idea X will suddenly feel much more important than B or C. Or we might start building out B, only to realize that it’s not what we want or it’s harder than we thought and want to bail on it.
That means no explicit promises and no implicit promises either. A list on the wall or in some official strategy document is an implicit promise: “this is what we’re doing next.“ There is no official list of what we’re doing next anywhere in the company.
I strongly believe in not writing down big ideas for a product, because if it really is a good idea it will resurface, preferably multiple times.
That said, client projects are different beasts than homegrown software. Clients expect roadmaps, and there's less wiggling room for features. You can't really skip expectations, clients expect them. Mapping client projects is a different puzzle to solve.