I'm often asked what it looks like to pitch an idea internally at 37signals. Since we don't do decks, or meetings, or long presentations, how is an idea actually presented?
Very simply. As a tight, concise write-up published as a document in Basecamp. A few hundred words. Sometimes with a low-fi sketch or two to drive a point home visually.
For example, we recently added a journal to HEY Calendar so people could log their thoughts, attached to a day.
This was the official pitch that @bb wrote up, and published to the Product Strategy project.
public.3.basecamp.com/p/o2BC3gFt7Sj6…
You'll notice there's not much there. Exactly. Pitches are directional ideas with a few boundaries to hold it together. Other than that, the team that's eventually going to build the feature has all the latitude they need to figure out all the implementation and design details that matter. You figure out the work by doing the work.
At 37signals, features are built and managed primarily by two people: One designer and one programmer. They run their own show, with occasional guidance, review, and editing from the outside when the time is right.
And this is the public announcement of the actual feature we shipped it:
updates.37signals.com/post/new-in-he…
There's more I can say, but would rather drive the discussion through questions you might have. Chime in and I'll respond here.
Very simply. As a tight, concise write-up published as a document in Basecamp. A few hundred words. Sometimes with a low-fi sketch or two to drive a point home visually.
For example, we recently added a journal to HEY Calendar so people could log their thoughts, attached to a day.
This was the official pitch that @bb wrote up, and published to the Product Strategy project.
public.3.basecamp.com/p/o2BC3gFt7Sj6…
You'll notice there's not much there. Exactly. Pitches are directional ideas with a few boundaries to hold it together. Other than that, the team that's eventually going to build the feature has all the latitude they need to figure out all the implementation and design details that matter. You figure out the work by doing the work.
At 37signals, features are built and managed primarily by two people: One designer and one programmer. They run their own show, with occasional guidance, review, and editing from the outside when the time is right.
And this is the public announcement of the actual feature we shipped it:
updates.37signals.com/post/new-in-he…
There's more I can say, but would rather drive the discussion through questions you might have. Chime in and I'll respond here.
You'll notice in the final public announcement there were decisions made that weren't in the initial pitch.
Like where the little notes icon went. A variety of mechanics around exposing or not exposing, for example. None of that stuff matters in the pitch. Spending any time on it would be a waste of time. In fact, in many companies, more time is spent describing things that don't matter than things that do.
The team working on it will figure it out. They'll be closer to it. They'll have more insights into it. Or they'll ask for someone else to chime in if they aren't sure, or want someone else's take.
Like where the little notes icon went. A variety of mechanics around exposing or not exposing, for example. None of that stuff matters in the pitch. Spending any time on it would be a waste of time. In fact, in many companies, more time is spent describing things that don't matter than things that do.
The team working on it will figure it out. They'll be closer to it. They'll have more insights into it. Or they'll ask for someone else to chime in if they aren't sure, or want someone else's take.
You'll also notice we don't estimate how long it will take.
Instead, we say how much time we'll give it. That's what we call the appetite. In this case it was 3 weeks.
The team then has to figure out the 3 week version of this feature. Because there's also a 6 week version. And a 9 week version. And I'm certain we could find a way to spend 3 months on it if we wanted. This is the problem with estimates — each one would be correct.
Appetites, on the other hand, are budgets. This is what we have, or what we're willing to spend. Make it work.
Instead, we say how much time we'll give it. That's what we call the appetite. In this case it was 3 weeks.
The team then has to figure out the 3 week version of this feature. Because there's also a 6 week version. And a 9 week version. And I'm certain we could find a way to spend 3 months on it if we wanted. This is the problem with estimates — each one would be correct.
Appetites, on the other hand, are budgets. This is what we have, or what we're willing to spend. Make it work.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
