One of the challenges we’re facing at the moment is how we handle feedback and ideas from our customers and other parts of the company.
In Shape Up I noticed this paragraph from chapter 3:
Our default response to any idea that comes up should be: “Interesting. Maybe some day.” In other words, a very soft “no” that leaves all our options open. We don’t put it in a backlog. We give it space so we can learn whether it’s really important and what it might entail.
I love the concept of not having a backlog and sign up for all the benefits of not having one, but I wonder if feedback doesn’t go there does it go somewhere else? I did notice in a livestream Basecamp did that the customer support team keep some loosely grouped documents of feedback and interviews with users on Basecamp.
I was wondering if anyone could share how they’re handling feedback and ideas. Are you keeping a record of them somewhere?
In my experience, it is hard to get to “backlog zero” if your company’s culture is used to managing backlogs.
In terms of customer feedback, while they may inform future pitches or provide signal for research, we generally don’t “keep” feedback anywhere near the Shape Up flow. I would let your customer support team keep track of that stuff independently, for whatever they need it for. Exception: I would “keep” any feedback that MUST be pitched and/or addressed in the next cycle or cool down. Feedback that’s both obvious + urgent should be fairly rare IMO.
In terms of ideas … unless someone turns it into a pitch it usually dies a quiet death after the current cycle ends. I actually do keep a list of ideas that come up during the current cycle from others, then toss it at the end of the cool-down cycle (e.g. right before the next cycle). I work under the belief that if the idea is strong enough, it’ll come up again. And that is good signal that there’s something there. (That said, if no one picks up the idea to pitch it, maybe it’s not a strong enough idea in the first place so who knows.)
tl;dr – Feel free to compile a list of ideas/feedback if it makes your team comfortable, but commit to deleting it once every eight weeks or more frequently to stay true to “backlog zero.” Good luck!
People at Basecamp keep all kinds of notes and documents all over the place.
The simple point is it’s different to have a bunch of notes lying around versus an official list of “things we are supposed to do one day.”
It’s the centralization into a single official place that is the problem, along with the expectation and heavy feeling of burden that these things somehow deserve attention in the future.
For example, Chase in Support might post a document about an interview he did with a customer to better understand a feature request. I’ll read it, and I might forget about it. Or I might read it, and think “oh that’s really interesting” and add it to my personal list of things to maybe shape in the next cycle.
I’ve found it sometimes helpful to talk about “decentralizing” the backlog. Hope that helps.
I recently introduced a fork of shape up to my team. This is how I recommend the team think about raw ideas. It maps to these 3 stages
Outside of shape up
Inspiration: Before you have a fully formed idea it’s usually sparked by something. A customer call, using the product yourself, feedback from support tickets, etc. This is tracked outside of shape up as a source of inspiration for raw ideas (see customer feedback section in screenshot).
Shower thought - Before you share an idea it usually sits in your head or scribbled on a scratchpad. The idea may be fully formed but it’s still intimate. It’s tracked personally how you see fit.
Inside shape up
Raw idea - When folks feel like an idea has enough potential they drop it into our raw ideas section within the shape up process (see screenshot). Anyone can pick up an idea to turn it into a pitch.
This is working for now but we’ll see how we need to adapt as ideas and people grow. Hope that helps!
As time goes on I’ll group bugs into a bug bash that aren’t critical like the ones mentioned above, but we should really fix. “Really fix” is a matter of taste, but something we have to be able to advocate for with data or personal interactions.
This one is called Bug bash: Tokyo and has 7-10 bugs that are described in a https://www.loom.com video. Loom has been great for detailing bugs
Then, it goes through the betting process against other product work. We decided to bet on Bug bash: Tokyo for this cycle along with 2 other projects. The point here is the bug bash still competes at the table.This is a bit of a hybrid between 2 and 3 detailed in shapeup.
The bugs space is separate from ideas. Right now, the team will drop non-critical bugs into the bug space. Then I’ll take a look at that each cycle and group them into something like Bug bash: Tokyo to bet on as a smaller stream during the cycle. Finding something similar is needed for a category called “tidy up.” Not a bug, not feature work, but certain areas in the product we know should be tidied up.
I believe Shape up refers to this as the cool down. I would love to get to a spot (when we have a couple more engineers on) where we have 1-2 people focusing on feature bets, and 1 person focused on a small stream of tidy up + bug smashing. Tidy ups and bug smashes will still need to be bet on for a given cycle so it’s the same spirit of not having interrupts during feature work.
There’s a bit of filtering that happens before people record it as a customer problem. Something like, “I don’t send emails because I can’t preview it before I hit send” is more likely to be tracked than, “I wanna be able see all my releases in a gantt chart” on the customer problems side of raw ideas. Hope that helps
