Has anyone tried the “Shape Up” method used by BaseCamp? What’s been the advantages and disadvantages to using this new methodology?
I haven’t fully implemented it, but I’m nudging my team in that direction. Historically, we’ve been pure Kanban. No sprints, just work on the next thing up. It caused scope creep and long times to completion since there was never a compelling reason to stop & move to the next thing.
I read Shape Up a few months ago and using some of the ideas in there, introduced the idea of an Investment Budget. It was a way to get around saying “deadline”, but that’s what it amounted to. The engineers bought into the idea since it gives them input on the design. If we budget a month for something, engineers will have to give feedback on what can accomplish the goal within that month. As it stands today, we create a beautiful, fully formed design and hand it over. Then 2 weeks later, we ask “when will this be done”.
I only introduced this idea to the engineers a little over a week ago, so it’s early days. If this goes well, I’ll have to uplevel it to scope out the full soup-to-nuts design and implementation investment.
Thanks @MichaelYoffe, for the insights. I finished Shaped Up a month ago as well and struggling to find different ways to implement as we have multiple teams working on different areas of a large product. I’m looking at trying this in isolation with one team that is building something greenfield. Like to hear how it goes with implementation. Thanks again.
You’re welcome, Happy to jump on a call sometime if you’d like.
If this call happens, would love to listen in as someone who has always been interested in implementing the ShapeUp methodology.
I think there are some great nuggets in Shape Up and also some serious limitations mostly around their org structure… Shape Up isn’t remolded for different organizations.
For instance, the team that implements has no time granted to generate a bid… without also losing their 2 weeks of “free” time.
I’ll say this, the idea of
no backlog is so uncomfortable for most people it’s a non-starter… which is sad because it’s definitely a good idea imho.
but I’ll +1 a call to talk about implementing it. I’d appreciate the thought exercise… basically a Shape Up Mastermind for you @Joel.
How does next Wednesday or Thursday morning work for everyone? I’m happy to share what we’ve started implementing and to open the conversation to others who want to contribute? I can set up the zoom. Let me know if this is something you’d want to attend.
I’m on PST, so late afternoon Monday would be better, but no need to schedule around me if I’m an outlier.
On MDT so similar… Truth is, I never know what conflicts will arise so pick a time and I’ll do my best to be there and contribute.
An excerpt by Micaela Neus, which I very much relate to myself. Am sure it would help y’all too.
Reading Shape Up made me admire Basecamp even more, and I would like to reflect on what has and hasn’t worked for me in the past. Most of my experiences have been at early startups and yet this methodology matches my intuitions despite being based on operations at a well-established company. I choose to believe this means the principles of innovation and joyful work apply no matter what your scale.
I found myself literally nodding in agreement as I read it, and have only two points to add based on my own experience in product.
1. Everything is made of people and anything they touch is the product.
The companies I most admire take a comprehensive approach to product design that goes well beyond their software. They map out the user’s journey from the beginning, lay smooth paths between likely destinations, and generally create experiences consistent with the company’s mission and brand at every waypoint.
Basecamp is one of these companies which leads me to believe they shape work according to this philosophy. If this idea is new to you, read this thread from Jesse Farmer.
2. Design thinking and taste is essential for a product manager
Basecamp lives and dies by design. It started as a web design agency, and Springer’s final interview involved redesigning Verizon’s website. I imagine that they continue to hire design-savvy folks for every position on their product team.
At teams where design played a smaller role in the company’s culture, a product manager might need to steer both the aesthetic and functional development of the product. The shaping method as outlined in the book doesn’t account for extremely early-stage products not yet supported by a design system. Team members tend to become better collaborators over time, which may mean that a product manager should hover a little more closely if the team is fresh.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.