Product Management Tactics — Break Up the Tasks
Break up work to make the tasks easier to accomplish. Singer suggests treating a high-level plan like a cut of meat. Some parts of the work are interconnected, but many operate independently. By “slicing” the bigger project into scopes, the team can prioritise the more important tasks. Decide what matters: not every scope should be treated equally.
Basecamp is certainly a unique organization. It doesn’t follow the mold of many other Silicon Valley “high growth or bust” tech companies. First off, it’s not based in Silicon Valley. Basecamp’s roots are in the Midwest, headquartered in Chicago, Illinois. Basecamp also hasn’t raised tens of millions of dollars from A-list investors in order to fund its growth trajectory. It is mostly a bootstrapped company (save for a sole investment it took on from Jeff Bezos… because… well… he’s Jeff Bezos). But its midwestern headquarters and bootstrap mentality isn’t what makes it truly unique. It’s how its team approaches the way it builds product.
In this case, Ryan Singer — Basecamp’s Head of Strategy — gives a glimpse into their process. Ryan shares that in lieu of the 2-week sprint followed by 2-week sprint approach that many other tech companies take — going as long as what’s required to complete a product or portion of a product — Basecamp approaches things differently. Instead, they have a 6-week work period and their rule is that whatever they set out to build has to be finished within that 6-week time period. No added time. No additional “sprints”. The work must be complete.
Admittedly, we at Product Collective haven’t been a part of product teams that have taken this approach. We’ve certainly seen our share of major products/features that ultimately end up taking months of work in order to finally be “complete.” To be fair, though, not many companies approach work the way that Basecamp does.
So, how does Basecamp practically do this? As Ryan Singer shares, one way is to cut the work up into chunks that can be focused on independently. The work can be completed much quicker if you’re not so worried, at first, about the way that the piece of product you’re working on fits into the rest of your product set.
But, is this practical? I can see lots of product and engineering teams, though, balking at this concept. After all, why spend time working on something that may require a lot of work later on trying to connect it to everything else.
Here’s the thing, though: It works for Basecamp.
This doesn’t mean that working this way will definitely work for you and your team. But it also means that this approach isn’t impossible.
Of course, the only way to really know is to try it out for yourself. So, when the time comes to have a planning meeting to focus on that next big feature you’ve agreed to launch — consider approaching things a different way. Maybe it works for the team, and maybe not. But you’ll likely learn something no matter what. And the best case scenario is that you’ll accomplish things much faster than you might otherwise have done so.