⏴Ryan Singer

Tags

Latest posts

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.)

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?

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
© 2025 Ryan Singer