PM Lessons I - Shape Up

This is the first blog of a series on lessons from the best books on building software products.

Backdrop

Working for four years with tech teams at startups has given me a first-hand view of how a product comes to life. Being curious about the non-technical aspects of the lifecycle of a product pushed me to explore more about product management (PM). There were multiple resources like MOOCs, blogs, and books to start with. Though blogs are great for getting an introduction, I found courses and books to be delving much deeper into the subject. I had fun doing University of Alberta’s course on Software Product Management last year - highly recommended if you want to get into the nitty-gritty of product management.

Books on PM

The next step is to explore the best books on building great software products. There are numerous blogs about reading-lists on PM & building great products in general. I feel sharing a short-summary or lessons from these books will be useful for the industry and nudge more people into reading them.

Without further ado, let’s dive into the first book.

PM Lessons: Shape Up

I am starting with a book titled Shape Up by Ryan Singer (Head of Strategy, Basecamp). It is an excellent take on the process of product development and is highly relevant for start-ups with growing tech teams. This book is available for free in here.

Here are my learnings from Shape Up:

• Shape the work before giving it to a team. Focus on appetite. Instead of asking how much time it will take to do some work, ask: How much time do we want to spend? How much is this idea worth?

• Principles of Shaping:
  • Wireframes are too concrete . Words are too abstract.
  • Properties of shaped work:
    • Rough: Enough flexibility for designers & programmers to think and apply their expertise
    • Solved: All main elements of solution are there at the macro level and they connect together
    • Bounded: Absolute clarity on what not to do
• Steps to shaping:
  • Set boundaries: Figure out how much time the raw idea is worth and how to define the problem. Default response to any idea that comes up should be: “Interesting. Maybe someday.” In other words, a very soft “no”.
  • Rough out the elements: Sketch a solution at a higher level of abstraction than wireframes in order to move fast and explore widely (Breadboarding / Fat-sketches).
  • Address risks and rabbit holes: Find holes or unanswered questions that could trip up the team. Solve them by cutting things out, or specifying details at tricky spots. Well-shaped work looks like a thin-tailed probability distribution. There’s a slight chance it could take an extra week but, no reason to go beyond that. Beware the simple question: “Is this possible?”. In software, everything is possible but nothing is free. Rather than asking “Is it possible to do X?” ask “Is X possible in 6-weeks?”
  • Write the pitch: The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations (No-gos). The pitch goes to the betting table for consideration.

• Bets, Not backlogs: A pitch is not tracked if it’s rejected for the current cycle. Anyone who wants to advocate for it again simply tracks it independently—their own way—and then lobbies for it six weeks later.

• Betting Six Weeks
  • Six weeks is long enough to finish something meaningful and still short enough to see the end from the beginning. Think like: “If this project ships after six weeks, we’ll be really happy. We’ll feel our time was well spent.”
  • Uninterrupted time: When you make a bet, you honor it. Do not allow the team to be interrupted or pulled away to do other things.
  • The circuit breaker: Teams have to ship the work within the amount of time that has been bet. If they don’t finish, by default the project doesn’t get an extension.
  • Fixing bugs: If it’s a crisis, drop everything and work on it. But crises are rare. The vast majority of bugs can wait six weeks or longer.
  • Think of screen space in terms of real estate: If we give that space to that button up now, we won’t be able to use it in the future. Are we selling it too cheaply to solve this particular problem?

• Hand Over responsibility: Don’t assign tasks to anyone. Trust the team to take on the entire project and work within the boundaries of the pitch. Give full responsibility to a small integrated team of designers and programmers.

• Get One Piece Done: Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, build one meaningful piece of the work end-to-end early on and then repeat. Work vertically on one small piece of the project instead of chipping away at the horizontal layers. Have something tangible and demo-able in the first week.

• Which piece to work on first? Core, small & Novel: Choose the feature which solves the core issue first & is small enough to demonstrate. In case of collision, chose the one which is more novel (the one which offers more learning for the team/ eliminates uncertainty).

• Map the Scopes: Organize work by structure, not by person. Segregate work by tasks that fit together (scopes). Scopes reflect the meaningful parts of the problem that can be completed independently and in a short period of time—a few days or less. They are bigger than tasks but much smaller than the overall project. Well-made scopes show the anatomy of the project.

• Use Hill Charts to show progress: Each dot represents a piece of work. Every piece of work has two phases. First there’s the uphill phase 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 of execution. Easy to execute once all unknowns are resolved.

• Decide When to Stop: Don’t aim for the ideal design/Code, compare down to baseline—the current reality for customers. How do customers solve this problem today, without this feature? Move from “never good enough” to “better than what they have now”.

• Scope Hammering: Divide features into Must-haves vs Nice-to-haves. Be brutal in this differentiation & its execution.

• On Testing:
  • Programmers write their own tests and ship features.
  • Think of QA as a level-up, not a gate or a check-point that all work must go through. Things are better off with QA than without it but don’t depend on QA to ship quality features that work as they should.

• Code review: Same as testing. The team can ship without waiting for a code review. There’s no formal check-point. But code review makes things better, so if there’s time and it makes sense, someone senior may look at the code and give feedback.

• Move On: Stay debt free after shipping features post a six-week betting cycle. A flood of new requests will come in - say a polite No and let the requests compete with everything else on the next betting table/ release cycle.