Hard Edges, Soft Middle

Res Extensa #16 :: The value of setting hard objectives, with space for experimenting with solutions; falling in love with the problem; setting boundaries & appetites

Have you had that feeling of being several weeks into a project, and you find yourself wandering around, struggling to wrangle the scope back to what you thought it was when you started?

It's an easy trap to fall into. It's why I'm always thinking about ways to make targets smaller (or closer, if you're thinking about real physical targets). The bigger and more ambitious you want to be with an objective, the more confidence you need to have that the objective is the right one. Often what happens is we decide a project scope — a feature or product prototype we think has legs — but the scope gets bigger than our confidence that we're right. A few weeks in and there's hedging, backtracking, redefining. You realize you went down a blind alley that's hard to double-back on.

I heard an interesting perspective on scopes and approaches to building. Think of the "scope" as the definition of what the project is seeking to do, and the approach as the how.

In an interview on David Perell's podcast, Ryan Singer made a comparison between having a hard outer boundary for the work with soft requirements on approach, versus rigid and specific micro-steps, without a solid fence around it, an unclear or amorphous objective. In his words: "hard walls with a soft middle" or "hard middle with a soft wall":

I've had this mental image that I haven't been able to shake that's working for me lately, which is what we're doing in Shape Up. We have a very hard outer wall for the work. And we have a soft middle. So there's a hard outer boundary perimeter — it's very fixed, it's going to be six weeks and we're doing this, and this is in the project, and this is out of the project, and this is what this solution more or less. Clear hard outer boundaries. But then the middle is totally like "hey, you guys figure it out." Right now what a lot of companies have is the opposite. They have a hard middle and a soft boundary. So what happens is they commit to this for the first two weeks, we're going to build this and we're going to build that, and we're going to build that all these little things. And these become tickets or issues or very specific things that have to get done. And then what happens the next two weeks you say, okay, now we're going to do this. You're specifying exactly what should go in the middle, and it just keeps growing outward because there's no firm boundary on the outside to contain it. So this is the the hard wall and the soft middle or the hard middle in the soft wall. I think our represent two very, very different approaches.

This requires trust in the product team to choose approach trade-offs wisely. If you encounter a code library in use for the feature that's heavily out of date, but the version update requires sweeping changes throughout the app, you'll need to pick your battles. Are you trying to build a v1.0 of a new feature, or are you trying to upgrade that library? A team with fixations on particular steps (the "hard middle") might decide too early that an adjacent feature needs rework¹. Before pulling up to a higher altitude to look at the entire forest, the team's already fixated on a particular tree.

Setting a hard edge with a soft middle defines what the field of play and game plan look like, but doesn't prescribe for the team what plays to run. The opposite model has a team hung up on specific play calls, with no sense for how far there is to run, or even how large the field is in the first place. When you grant the team the freedom to make the tactical choices, everyone knows there's some freedom, but it isn't infinite. The team can explore and experiment to a point, but doesn't have forever to mess around. If you choose to work in the Shape Up-style 6 week cycle, decision velocity on your approaches has to be pretty high to hit your targets.

Any creative work benefits from boundaries, from having constraints on what can be done. The writer is constrained by a deadline or word count. The artist is constrained by the canvas and medium. A product team should be constrained by a hard goal line in terms of time or objective, or preferably both.

Some of the best work I've ever been a part of happened when we chose particular things we weren't going to do — when we intentionally blocked specific paths for ourselves for some cost/benefit/time balance. Boundaries allow us to focus on fewer possibilities and give greater useful, serious attention to fewer options. We can strongly consider 10 approaches rather than poorly considering 50 (or, even worse, becoming attached to a specific one before we've explored any others).

Premature marriage to specific tactics pins you to the ground at the time when you need some space to explore. Because you've locked yourself into a particular approach too early, it may require tons of effort and time to navigate from your starting point to the right end point. You may end up having to do gymnastics to make your particular decided-upon solution fit a problem you can find (a solution in search of a problem).

Hard edge, soft middle reminds me of a favorite philosophy from the sage Jeff Bezos, talking about Amazon's aggressive, experimental, but intentional operating culture:

"Be stubborn on the vision, but flexible on the details."

Love the Problem

Marty Cagan talks about some similar concepts to this in Inspired, his first book on product management philosophy. One of his principles of product vision that comes to mind is salient here:

Love the problem, not the solution

One of the biggest lessons to learn in product development is realizing there are things we can't know. Or at least can't know right now, at the beginning of a project. With this universal truth accepted, the best path to take is the one that sets up targets for problems we do know, and provides a guarded space for experimenting within that boundary for solutions that get at the problem. For product teams, you’re better off saving your love for the problem rather than the solution. You benefit much more from spending cycles observing and refining your understanding of a problem. The more time spent here, the less you should have to spend agonizing over solutions. With the right distribution of attention, many solutions will fall off the table as irrelevant if you refine the problem properly.

Shaping and Appetites

Singer's Shape Up is all about this idea. The "hard edge" in Shape Up lingo comes from combining the shaping process with the setting of an appetite. Shaping molds our understanding of the problem into something that can be solved with some feasible, viable, attainable solution. The appetite helps think through the future state, and how much we want to get there: if we can solve this problem, to this degree of completeness, what amount of time would that take? If the answer is "8 weeks", we may only have an appetite to devote 4 weeks to a solution for that particular problem. So, back to the drawing board...

Perhaps with some refinement of our problem definition, we land on an estimate of 5 weeks, and that stretch feels okay to get a solution in place to build on top of incrementally. Trade-off balanced, solution achieved, in a reasonable time frame we can work with.

Importantly, what really bubbles up through the (usually messy) process of shaping and appetite-setting is this hard edge within which to experiment with specific solutions.

1. What you "need" to do is a dangerous trigger word. Almost always the perceived need is based on a particular understanding of trade-offs that could be misguided. One engineer's need to recover some technical debt (while noble, of course) might be the opposite for CEO, who might be seeing a bigger picture existential need to the business. A thing is only "more needed" relative to something else.