Ryan Singer: A better way to plan, build, and ship products
Skip the fluff. Hear the best bits.
Just 5 minutes. All value, no filler.
đ Key Takeaways
đ You can't build a new room without knowing what's inside the wall. Shaping sessions force teamsâengineering, product, and designâto align before work begins. You set a time limit first, then shape an idea to fit that limit. No vague concepts. No endless planning. Start from the end and work backward. Ship plans, not guesses.
đ Shape Up replaces deadlines with appetites. Instead of asking how long a project will take, ask how much time you're willing to spend. Then shape the work to fit. Whether it's a two-week landing page or a six-week feature, the scope bendsânot the time. Time is fixed. Scope is flexible.
đ Good shaping makes building feel like cooking. When a project is well-shaped, the build team works like a focused kitchen. No distractions. No constant clarification. Just momentum. But to get that clarity, the shaping must happen firstâwith all three disciplines in the room. No shaping, no shipping.
đ A clear problem makes shaping possible. Donât shape âcalendar.â Shape âa way to see empty spaces in the schedule.â Thatâs the difference between a fuzzy wishlist and a buildable solution. Framing tightens the problem. Shaping makes the solution real. Ambiguity kills delivery.
đ A good shape has fewer than 10 moving parts. You should be able to explain the core pieces of the solution in one breath. Not 50 tickets. Not a 30-page PRD. Just a crisp summary of what gets builtâand why it matters. If the team can't hold it in their head, it's not ready.
đ Engineers must be in the shaping room. Without engineering, shaping becomes fiction. Youâll miss edge cases, overpromise, and collapse in build. The right engineerâone who knows the codebase deeplyâwill surface hidden complexity before it explodes. Nothing derails builds faster than invisible risks.
đ Figma isn't shaping. Beautiful mockups create false confidence. But the goal isnât polishâitâs clarity. Shaping uses low-fidelity sketches to align on concept, not detail. Youâre designing direction, not deliverables. Fat marker drawings beat high-res dreams.
đ Don't kick off what you canât clearly describe. If your build team canât summarise the project in nine chunks or fewer, youâre not ready. Nine is enough to plan and trackâwithout drowning in tickets. Less is focus. More is noise. Simple plans scale. Complex ones stall.
đ Scrumâs rituals donât guarantee delivery. Shape Up replaces sprints and standups with clear bets and real ownership. Teams get a whole idea and a fixed time to execute. They create their own tasks. No middlemen. No micromanagement. Trust the team with the full picture.
đ Cutting scope at the end means you shaped it wrong. You donât wait for week five to discover itâs too big. Thatâs shapingâs jobâfront-load the hard decisions. If the team canât finish, pull it back into shaping. Donât just hack off features. Half-built work is wasted energy.
đ You donât need to do all of Shape Up to start. Pick one piece. Try a shaping session. Set a fixed appetite. Run a pilot project. This isn't an all-or-nothing religion. It's a toolkit for escaping delivery hell. Start with one problem. Learn from the results.
đ Shape Up thrives in real-world constraints. Itâs not just for Basecamp. Teams in startups, scaleups, and massive enterprises are using it. You donât need to burn down your process. Just carve out one team, one project, one bet. One cycle proves the model.
đ Shaping helps you ship fastâwithout chaos. Most teams arenât feature factories. Theyâre feature traffic jams. Work piles up, delivery stalls, and no one knows why. Shape Up solves that by aligning early, cutting fluff, and focusing on whatâs real. Itâs not velocity. Itâs clarity.
đ Product managers move upstream. Instead of running rituals and writing tickets, PMs dig into problems, frame the opportunity, and shape the solution. They become strategists, not schedulers. Build the right thing. Let the team build it right.
Actionable Plan
đ Set a maximum timebox (e.g., 6 weeks) for completing a project before starting any work.
đ Define your appetite upfront â decide how much time you're willing to spend on a project before shaping the solution.
đ Conduct a shaping session with a senior engineer, designer, and product person in the same room to co-create the solution.
đ Frame the problem narrowly before shaping â define exactly what user issue you're solving (e.g., "users canât see empty calendar spaces").
đ Create a sketch or breadboard diagram (not a spec or Figma file) of the key screens, flows, and logic that the entire team can understand.
đ Ensure the shaped idea includes fewer than 10 moving parts that can be clearly explained and visualised.
đ Kick off the project with the implementation team by translating the shaped idea into 9 (or fewer) major build scopes.
đ Let the build team define their own tasks based on the shaped idea and the 9-scope structure â do not create tickets for them.
đ Use the timebox as a hard stop â do not extend the project; instead, return to shaping if it's not on track.
đ Pilot the process on one meaningful project by shaping it fully, setting a fixed timebox, and tracking whether it ships on time.
đŹ Top Quotes
We are not going to start something unless we can see the end from the beginning. We're not going to take a big concept and then say, what's the estimate for this thing? We're going to go the other way around and we're going to say, what is the maximum amount of time we're willing to go before we actually finish something?
There was always this really intense urgency from both Jason and David, like, we've got to get to something we can ship. We have to finish this and move on. We have to get to something that's done. There was just no tolerance for kind of big things that got fuzzy and started to drag
If we shape a solution that is from a experienced standpoint, from a functionality standpoint, from a technical standpoint, doable and desirable, something that we can make happen in that amount of time, then we can give it to a team and we don't have to do the... paper shredder
We can't just take any project no matter how giant it is and then throw it at a team and say, figure it out and ship something meaningful in six weeks by cutting away scope, right?
The PM is less busy with how do I get this project to like not be in a bad state when it's getting built? And they're way more in how do I understand the business context? How do I narrow down the problem?
If you have someone who's at a senior level on the engineering side who is able to make the right architectural choices and also do some negotiating and kind of be the backstop to make sure that someone isn't going to get pulled away onto something else, you know, you can really get a lot done
What we need to do in a shaping session when it's going well is we come out with some kind of drawing or diagram where engineers, product and design are all looking at that and they're saying we understand that. I know exactly what to go build
If we want that team to be really using that time well, where they are moving, they understand what they're solving and they're creatively engaged because they know what it's supposed to be doing, right? You know, they need to have that clarity both on the problem side and on the solution side
What I often see is if there's someone on the build team who really feels that they should be involved in the fundamental decisions about the approach, then a better solution would be to actually bring them into the shaping and have them play that technical role in the shaping session
If we just did this on one of those branches, would it be a win? You know, and like if we did it on all three, how much more time would we have to negotiate for? And would it feel worth it?
There are so many unknowns and time bombs waiting in those tickets that sound reasonable, but they weren't really created by the person who understands the work that needs to happen, you know?
The shaping work is more, what are our options for the solution? And if the problem is too fuzzy and big, if the problem is just calendar, you know, and the shaping is going to be this ever expanding, never-ending thing, and we're not going to be able to get anywhere
When we try to read it, because it wasn't shaped and we didn't get down to, it's this, it's that, it's that, and that's how it works, it's hard to walk away from reading that and kind of have anything that's in your head
Usually the main tipping point, if we start from smaller to big is, you know, there's a phase when the founders are still involved in everything. And so it doesn't matter what your process is, it's going to be fine. But then you start to hire the first other people. And then for the first time, you try to delegate some of those things and the founders try to be less involved. And that's often where a lot of these problems start to appear
