Shape Up is a book written by Ryan Singer, the Head of Product Strategy at Basecamp. A masterpiece. This book explains the intricacies of planning, decision-making, and execution like none other, with real everyday examples and actionable suggestions.
It starts with the principles of shaping. The right level of abstraction, as it explains, is neither too vague nor too concrete.
Wireframes, for example, are too concrete and define too much detail too early, leaving designers no room for creativity. A wireframe or a mock-up will definitely bias the designer’s opinion especially if you’re in a higher position than them.
At the same time, words are too abstract and don’t provide enough information to make trade-offs. While over-specifying leads to estimation errors, under-specified projects usually grow out of control as there is no clear definition of scope.
The first of the three properties of Shaped Work, as the book defines, is that it's rough, allowing Designers and Programmers the room to apply their own judgment and expertise and discover all the real trade-offs that emerge. The second property demands that despite being rough and unfinished, all the main elements of the solutions must be there at the macro level and they must connect together. The last property directs for boundedness and indicates what not to do, telling the team where to stop.
The four major steps to Shaping Up are:
1. Set boundaries - Problem Definition and Time allocation
2. Rough out the elements - At a higher level of abstraction than wireframes to move fast and explore a wide enough range of possibilities
3. Address risks and rabbit holes - Amend solutions accordingly and add specific details at tricky spots
4. Write the pitch - Summary of problems, constraints, solutions, rabbit holes, and limitations.
At Basecamp, as the book explains, the pitch goes to the betting table for consideration.
There are five major questions that get asked at the betting table:
1. Does the problem matter? If yes, how important is it than the other problems?
2. Is the appetite right?
3. Is the solution attractive?
4. Is this the right time?
5. Are the right people available?
If the project gets chosen, the pitch is then re-used at the kick-off to explain the project to the team. Before each six-week cycle, the team holds a betting table where stakeholders decide what to do in the next cycle. At the betting table, they look at pitches from the last six weeks — or any pitches that somebody purposefully revived and lobbied for again.
Now, the first question that came to my mind, was why not have a traditional backlog? Backlogs, as the book claims, are big-time wasters. The time spent constantly reviewing, grooming, and organizing old ideas prevents everyone from moving forward on the timely projects that really matter at the moment.
The second question in my mind was, why exactly six weeks? The logic is beautifully explained in the book. A cycle must be long enough to finish a whole project, start to end, and at the same time, be short enough to see the end from the beginning. People need to feel the deadline looming in order to make trade-offs. If the deadline is too distant and abstract at the start, teams will naturally wander and use time inefficiently until the deadline starts to get closer and feel real.
The book also explains the role of constraint in prioritization using the example of a book. With a deadline constraint, a writer has to choose between fixing typos or adding a new section to a chapter. Without the pressure of the fixed deadline, he wouldn't make the trade-offs.
A practical example that explains the power of understanding a problem and narrowing it states that for a particular problem, instead of investing development time of 6 weeks to create a rule preventing some people from performing an action, they put a warning on the action that explained the impact, reducing the development time to 1 day.
Not just the problem, but the solution needs to be analyzed too. One efficient way to do that is to walk through a use case in slow motion. Given the sketched solution, how exactly would a user get from point A to point B? Slowing down and playing it out can reveal gaps or missing pieces that we need to design.
The three signs that indicate when the scopes are right are:
1. You feel like you can see the whole project and nothing important that worries you is hidden down in the details.
2. Conversations about the project become more flowing because the scopes give you the right language.
3. When new tasks come up, you know where to put them. The scopes act like buckets that you can easily lob new tasks into.
Risk, at Basecamp, is intentionally created for the project. Teams have to ship the work within the amount of time that they bet. If they don’t finish, by default the project doesn’t get an extension. This sounds severe but it’s extremely helpful for everyone involved. First, it eliminates the risk of runaway projects. Second, if a project isn’t finished in six weeks, it means the team did something wrong in the shaping. Instead of investing more time in a bad approach, it pushes them to reframe the problem. Finally, it motivates teams to take more ownership of their projects. That includes making trade-offs about implementation details and choosing where to cut scope.
Okay. Now comes the best part. If the teams aren’t interrupted in the six-week cycle, how do they handle bugs that come up?
For that, first, we should step back and question our assumptions about bugs. There is nothing special about bugs that makes them automatically more important than everything else. The mere fact that something is a bug does not give us an excuse to interrupt ourselves or other people. All software has bugs. The question is: how severe are they? In case of crises, we'll drop everything to fix it, but crises are rare, the vast majority can wait six weeks. It can be fixed during cool-down or can be brought to the betting table or a bug smash can be scheduled.
The execution methodology, explained in the book, is equally magnificent. One particular sentence that I totally agree with, from the book, was “The way to really figure out what needs to be done is to start doing real work.”
A team, as the book prescribes, should aim to make something tangible and demoable early—in the first week or so. That requires integrating vertically on one small piece of the project instead of chipping away at the horizontal layers. Suppose the project starts with a lot of design. The team could design a variety of screens and even implement them as templates or views. But until they’re wired to a backend, nothing does anything. The work remains hypothetical and speculative.
What it suggests, instead, is to pick off one slice of the project to integrate. Then when that’s done, the team has something tangible that they’ve proven to work (or not work and reconsider). Anyone can click through the interaction and see if the feature does what it should and if what it does is what they want. The point is to create a back-and-forth between design and programming on the same piece of the product. Instead of one big hand-off, take turns layering in affordances, code, and visual styling. Step by step, click through the real working feature-in-progress to judge how it’s coming and what to do next.
Every piece of work has two phases. First, there’s the uphill phase (Unknown) of figuring out what our approach is and what we’re going to do. Then, once we can see all the work involved, there’s the downhill phase (Known) of execution.
Journalists have a concept called the “inverted pyramid.” The idea is their articles start with the most essential information at the top, then they add details and background information in decreasing order of importance. This allows print newspaper designers to get the crucial part of the story on the front page and cut the end as needed without losing anything essential. Effective teams sequence their problem-solving in the same way. They choose the most important problems first with the most unknowns, get them to the top of the hill, and leave the things that are the most routine or least worrisome for last. As the end of the cycle approaches, teams should have finished the important things and left a variety of “nice to haves” and “maybes” lingering around.
Designers and programmers always want to do their best work. If we aim for an ideal perfect design, we’ll never get there. At the same time, standards of quality cannot be lowered. Then, how do we make the call to say what we have is good enough and move on? Instead of comparing up against the ideal, compare down to the baseline—the current reality for customers. It’s the difference between “never good enough” and “better than what they have now.” We can say “Okay, this isn’t perfect, but it definitely works, and customers will feel like this is a big improvement for them.”
These were some of my major learnings from the book. Books like these open up newer avenues of thought about Project/Product/Team Management. Now, definitely, some aspects of these won’t directly be applicable or executable in bigger, more complex organizations given the sheer complexity of team structures and projects, but then it does evoke the thought towards the need to think lean and execute agile.
Comments