ShapeUp Methodology

Over the last few years, I've become increasingly interested in how teams work together, not just what they're building.

As an engineer with a design background, I've always cared a lot about process. Not in a corporate buzzword kind of way, but in a very practical sense. The way a team communicates, plans, scopes work, handles ambiguity, and makes decisions has a massive impact on the quality of the product and the well-being of the people building it.

I've worked in environments that felt incredibly collaborative and focused. I've also worked in environments where priorities changed daily, deadlines constantly shifted, and everyone was operating in a permanent state of urgency.

The difference between those two experiences is hard to overstate.

One of the methodologies that has resonated with me the most recently is Shape Up by Ryan Singer.

The core idea is refreshingly simple: teams do better work when they have clear problems to solve, enough autonomy to solve them, and protected time to actually focus. That sounds obvious, but it feels surprisingly rare.

A lot of modern product development feels built around interruption. Constant meetings. Endless backlog grooming. Priorities shifting every few days. Teams spending more time estimating work than doing the work itself. Shape Up approaches things differently and it's been really validating to read through their (free) e-book and see a lot of the experiences I've had highlighted.

Instead of over-specifying every tiny implementation detail upfront, the work is shaped enough to define boundaries and intent, while still giving the team ownership over execution. Projects are scoped into fixed time horizons, which forces prioritization and tradeoffs early instead of allowing work to endlessly expand.

And maybe most importantly, it values focus. That part immediately clicked for me.

Some of the best work I've done in my career happened when I had uninterrupted time to deeply understand a problem, collaborate closely with smart people, and iterate intentionally without constant context switching. I think a lot of engineers and designers crave that kind of environment.

There's also something I appreciate philosophically about Shape Up: it acknowledges uncertainty honestly. Instead of pretending we can perfectly predict software development six months in advance, it creates systems that work with uncertainty instead of against it.

As someone who's worked across both design and engineering, I also love how collaborative the methodology feels. Good products rarely come from isolated departments handing work off to one another. They come from people thinking together early, asking hard questions, challenging assumptions, and solving problems collectively.

That's where I think the best teams shine. Not in shipping the most tickets or having the busiest sprint board, but in creating enough clarity and trust that people can do meaningful work without drowning in process noise.

The more I learn about Shape Up, the more it feels aligned with how I naturally think about product development and healthy teams.

I'm especially excited about what we're building at Virtu.

Our team is building project management software inspired by Shape Up methodology, focused on clarity, collaboration, and creating healthier workflows for modern product teams.

We're in beta testing right now and will be sharing very, very soon. I can't wait!