Differentiating instead of competing
Since I wrote a book about how we do product development at Basecamp, I've found myself in a position I don't want: methodology preacher.
This came to a head after I spoke at the UXDX conference. Marty Cagan was also a guest, and he gave very different advice about how people on a product team should work together.
Afterward, a debate erupted on Twitter around these questions: Who's right? Who "should" define the work? Who "should" set the strategy? What "should" the development team be responsible for?
This is what head-on competition looks like. There's one position to stand in ("the best way", "what people should do...") and more than one person trying to stand there. When there's just one spot to claim (only one way can be "the best") you have to push each other off to try and hold the position.
As soon as I recognized the push-and-shove feeling, I remembered: Wait, this can be so much easier. Shape Up is for a specific circumstance and a specific desired outcome.
That's demand-side differentiation. Supply-side differentiation is well-known. It's when your product is different. Demand-side differentiation is when the circumstance your product improves is different.
By defining a smaller, more specific circumstance, we define a different "spot" to fight over. And there are lots of spots where nobody else is there to fight. (This is what "non-consumption" ala Clay Christensen and "blue oceans" in Blue Ocean Strategy are about.)
Shape Up isn't for all product teams. It's especially for leaders of teams who say to themselves: "We can't just keep doing small-impact projects. Now that we're bigger, when we try to do high-impact projects, they drag on forever. How can we get back to shipping something important and customer-facing?"
To me this felt like a sigh of relief. I'd much rather have the solution for a valuable special case than try and argue about what is right for everyone.
|
|
"Unfolding" the interrelationship diagram
A while back, I learned this technique from Bob.
Sometimes I'm working on a design problem, and there are too many things to solve. They all seem tangled together, and I don't know where to start. I'm afraid that if I start on the wrong thing, I'll paint myself in a corner or go down the wrong path and have to start all over again.
A tool to deal with this is the "interrelationship diagram." It's a systems-thinking thing. Basically, you brain dump all of the disconnected parts and figure out what is connected to what. Then you can identify the bigger chunks to work on and see which chunk to do first.
It works like this. First you write down every thing you think you have to build and number each one. Then arrange the numbers around a circle:
|
|
|
Then, draw an arrow when doing one thing will help you to do the other thing. This reveals the causal structure of how things are connected.
|
|
Last, you count the arrows to see which things have more outgoing than incoming connections. Those are the things that have more influence on the rest of the system and should be solved first. In this case, #2 is the thing to do first, because things #5 and #6 depend on it, and that unlocks doing #4.
You can do this on paper or a whiteboard. Lately I've been making them in OmniGraffle, and this led to a surprising next step.
Here's a real project from last week. I brain dumped a list of pieces from the design that were in my head and drew connections between them.
|
|
|
Now the cool thing. Because OmniGraffle is a diagramming tool, the arrows are all connected magnetically to the text labels and they stretch as you move the labels around. That means that after the connections were defined, I could drag the labels around to "unfold" the network.
|
|
Now that it's unfolded, I do could more than just count the incoming and outgoing arrows. This flattened version of the network made it easier to see the bigger chunks of things.
From here, it was natural to draw borders around the main chunks. Each chunk is a part of the network with more internal dependencies than external dependencies. (If you know Notes on the Synthesis of Form, this may give you flashbacks.)
|
|
First I drew the borders, and then I wrote names to describe the contents of each chunk. Wait a minute ... this is the same thing as scope mapping in Shape Up. These are scopes!
From here, I could reduce the network to just the scopes and define a sequence to tackle them.
|
|
|
This gave me more confidence to dive into the weeds. I started on the first scope ("Add"), looked at the everything in its local network, and started sketching.
|
|
Plus: Quick takes
- Product companies and "fixed output." Some people adopting Shape Up struggle with interruptions from their sales team. The adopter is trying to schedule uninterrupted work on "the product" or "the platform." Sales regularly tells them to drop what they're doing and build some custom feature to close a deal. I suspected this mismatch has to do with business model and dug into it. People use the term "product company" and talk about "product development" in two kinds of companies: ones where they sell the exact same thing to everybody, and others where they build custom capability to close deals. I found sources that suggest these are two different business models: value-added processes vs solution shops. But the VAP definition doesn't map very well to software. A better definition I've been using since then, thanks to Jason Hwang, is "fixed output." A company that delivers the same thing to all customers is going to be organized differently than one that does things made-to-order.
- Naming things last. Note how, in the case study above, the names of the scopes came last in the sequence of the process. I'm noticing this is a powerful and maybe under-appreciated pattern. Very often we try to come up with categories or ways of chunking things straight away. Look at all the work that preceded the naming above — that created structure to name. This comes up in demand-side research too. I've seen some teams ask "what's the job to be done?" and then whip up a statement. I've learned to only attempt to name a job after I've done interviews, affinitized patterns in the interviews, coded and clustered based on the patterns, detailed the clusters, and iterated on that whole loop two or three times. Only then do I feel informed enough to try and title the thing with a name!
|
|
|
React
I'm using this newsletter both to share and to learn.
Have you tried similar things? Are you doing something different? Struggled with the same challenges? What's your experience?
Replies to this email go straight to my inbox.
|
|
|
|
|
|
