Articles

• When engineers say "that'll take months!"

  Igor writes: "Our product is 15 years old, with a lot of legacy code and outdated technologies. Our engineers say that the minimum time they need to ship anything of real value (not just small things) is about three months...

• Not everyone needs to be talking to customers

  On relying on each others' expertise instead of trying to pull everyone into the same work.

• We did all this discovery... now how do we decide?

  On how to weigh the impact when we've gathered too many inputs to choose from.

• What's the unit of impact?

  Different moments in the company call for green-lighting different projects. What counts as "impactful" depends on what we're trying to do.

• The cost of not shaping

  A founder came to me with questions about his team's results adopting Shape Up. Some projects were knockouts. They got exactly what they wanted done, when they wanted it done. But other projects dragged on, stuck at the last yard line. What was going on?

• Shaping isn't writing

  Shaping isn't writing. It's not filling out a template or creating a document. It's getting to that "a-ha" moment together where the parts crystalize and we have something that will work. (Plus an example of how messy a real shaping session looks.)

• Three "what about...?" questions when considering Shape Up

  Questions about roadmaps, betting at the last minute, iterations, and how shipping what we intended is like driving a car.

• Step change

  The recent wave of layoffs reveals something tricky about the notion of "empowered" product teams. There's a missing ingredient that seems to separate the teams who get cut from the teams who survive.

• La Product Conf, Paris

  La Product Conf shared the video from my recent talk in Paris: "Scaling Shape Up Beyond Bootstrapped Companies."

• Noise factors vs. control factors

  On the latest Circuit Breaker podcast, Bob and Greg talked about causal structures. This is when you’re trying to improve a system and, in order to get the effect you want, you first try to understand the mechanism of how the system works. At 9:00 Bob gave an

• Fintech Devcon, Denver

  I gave a talk together with Chris Spiek, CPO at Autobooks. We told the story of how Autobooks realized they could no longer apply Shape Up "by the book" and the challenges they faced. Intense growth and new technical challenges led them to bring me in to define

• Design systems, modularity and interdependence

  This post on LinkedIn got me thinking: If organisations want to move away from B-grade app experiences, they need to recognise Dev and Design are two distinctly different skill sets. Both require an amount of time to master. Therefore pointing a Dev to design system won’t result in consumer

• Prototyping to learn

  The latest Circuit Breaker podcast with Bob and Greg goes into incredible depth on "Prototyping to Learn". When Bob first told me about his approach to prototyping, I balked. The idea of building out multiple versions of something seemed wasteful, like going backwards or sideways instead of forwards.

• Framing

  Over the last few months I've worked with teams to help them adapt Shape Up to their specific context. Talking to a wider variety of teams has been eye-opening. It's helped me discover many hidden factors that were present at Basecamp when I first wrote the

• Shaping Up Client Work

  I talked with Bruce van Zyl about his experiences working with clients using Shape Up.

• Dependencies vs. unknowns when sequencing

  A good question came up from a long-time Shape Up adopter: I’ve noticed you mention two slightly different methods for sequencing: - The interrelationships diagram - Getting to the most unknowns first Have you landed on a preference yet? Are there circumstances where one is better than the other?

• News: I'm giving a workshop on how to hand off and break down work

  I'm interrupting the normal newsletter format to let you know about a workshop I'm giving. It's called The Confident Handoff. I'm giving it remotely to a small group of early adopters on November 22-23, 2021. Handoff is that point in time where

• Shape Up is for features, not all development work

  I'm seeing a pattern among successful Shape Up teams. Companies first try Shape Up on a product team that builds features. They discover a new rhythm of shaping and shipping meaningful changes, and it feels like a victory. Then, they think "well since Shape Up is working

• "Done" is relative to what comes next

  Right now I'm at the very beginning of a project with lots of unknowns. Starting it exposed me to a common pitfall where scope expands very early in the first steps of a project. I want to prototype a drag and drop interface to do this kick-off exercise.

• Systemizing kick-off

  Recently I tried a new exercise to systemize the way we kick off projects. Kick-off is that moment when the person who shaped the work hands it off to the development team. It's an important moment in Shape Up because the dev team takes full responsibility for interpreting

• Small tools for shaping

  I'm experimenting with ways to demonstrate the path from a raw idea to a well-shaped pitch. That is, how to go from "I think we should spend time on X" to "here's a specific concept for X that we're confident we

• Beyond to-dos

  When work is turned into tickets, our brains shut off. In ticket-land, the work is a given, and it's just a matter of "doing it." This is true for any traditional to-do software. The thing is, when smart people tackle work, they actually do work on

• Matching problems to business imperatives

  I keep getting questions about the work that happens before shaping a project. How do we decide if a problem is worth shaping? When does a problem deserve further research to frame the problem better? To answer this, our natural instinct is to weigh problems against each other. We ask

• Research gives us the problem, not the answer

  I often get asked about how research fits into timeboxed work. If a team is working in a cycle and they can’t decide on a direction, should they do research? How do they fit that in a fixed timebox? This cuts to a fundamental question of where research belongs.

• Some solution vs. no solution

  It’s natural to argue over what is the best, most perfect solution. Who would want to build anything less? This is especially true when we have our design or development hats on with a specific idea we hope to see in the final product. But it turns out that

• Shorthand for shaping

  Here’s a look at some shorthand I’ve been playing with, early in the shaping process. I use this when I have a bunch of stuff in my head for a design but I don’t know where to start. I don’t know if all the pieces are

• Orthogonality is a choice

  There are many definitions of orthogonality. For the overlapping worlds of design, engineering and business, we can summarize with this question: what needs to be solved together as one whole, and what can be solved separately? Two things are orthogonal if we can work on one of them without having

• Work that energizes

  After a few newsletters about defining work with pattern languages, a friend of mine said: "I don't get it. These pattern languages just look like outlines or specs. What's different?" Well, okay ... at one level it is just a spec. And maybe focusing too

• Measuring usage with a Taguchi signal/noise ratio

  Bob's been slowly schooling me in Taguchi methods over the last couple years. I'm starting to make some small steps towards applying them to software projects. My favorite so far is the signal/noise metric. Here's how I understand it so far. How do

• Shaping with pattern languages

  I'm re-reading Battle by Christopher Alexander. It shows the exact steps he took to design and build the Eishin Campus in Japan. I feel like a student in a master class when I'm reading this. The phases he went through map very well to Shape Up

• Shaping on the demand side

  One day, back in April, I was shaping some work for Basecamp 4 (the next version of Basecamp that we're planning to build next year). At 4:00 p.m. I got an alert from Basecamp's Automated Check-in, asking: "What have you worked on?"

• 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

• Christopher Alexander: A Primer

  Christopher Alexander’s work is hard to get into. He’s written over 15 books, and there isn't one that serves as a general intro or overview for the rest. In this livestream, I gave an informal introduction to what I think are the most important ideas in

• Interview with Adam Wathan

  I interviewed Adam Wathan about how his team adopted Shape Up and answered some questions.

• Longitudinal analytics

  Analytics apps don't tell you much about usage behavior. You might be able to see how many users performed an event, or how many times they did it. But none of the analytics packages out there are good at showing you how often people do things. Are they

• Products Are Functions

  Products are easier to reason about when you think of them as functions. They transform an input situation into an output situation. This lets you describe what the product does as a transformation of the user's circumstance instead of a bundle of features. How a product is like

• Mind the Product, SF: Product Development Tools

  A first look at breadboarding and decomposing a project into scopes. It was a blast to share the stage with Kathy Sierra.

• Vital Elements of the Product Design Process

  Product design can look like magic. When I started doing it ten years ago, the small team I worked on made decisions intuitively. There was no system and it worked fine. But as the company grew, I found myself unblocking teams and diagnosing problems. When I saw patterns repeating themselves

• What UI really is (and how UX confuses matters)

  People mix the terms UI and UX together. UX is tricky because it doesn’t refer to any one thing. Interface design, visual styling, code performance, uptime, and feature set all contribute to the user’s “experience.” Books on UX further complicate matters by including research methods and development methodologies.

• UI and Capability

  It’s easy to get overwhelmed with details when you’re designing a UI. That’s why I try to keep hold of which things “really matter” and continually come back to them. In a software tool, the important things are the capabilities you give your users. People use your

• Managing Product Development by Integrating Around Concerns

  I’ve been asked to explain my approach to managing product development. This topic applies to individual designers and programmers as much as managers. The goal is not to take what we already do and do it faster or more efficiently. The goal is to have more information and flexibility

• Thinking of interfaces as sets of jobs

  What is at the core of an interface design? I think of the design not as a collection of screens or buttons or pixels, but as a collection of jobs that the user wants to do. In this article I want to give you a feeling for how to think

• Future of Web Apps, London

  Here's a talk I gave at Future of Web Apps 2010 in London. I I walk through the steps of creating a web app including modeling, sketching, HTML, Photoshop explorations, and moving from static mockups to live running code. Each step is illustrated with a real example, including

• Designing with Forces: How to Apply Christopher Alexander in Everyday Work

  I gave this talk at the School of Visual Arts in NYC as part of the MFA Interaction Design program.

• An Introduction to Using Patterns in Web Design

  The biggest challenge for web designers is the unthinkably huge number of possible ways to solve any given problem. We usually don't think of this because we have our habits and traditions to fall back on, but there are literally billions of possible pixel combinations for each page