Before joining 37signals, I led product at a startup. We built an app for companies, helping employees know who’s who, who does what, who’s out, etc… We raised venture capital and over the next 8 years, expanded and improved the product. The company was acquired about a year after I left.
The product was a solid success and we were profitable when we chose to be, but not a runaway hit. We ran lean, with about 35 employees at the peak.
Eight years on a product is a long time. During those years, I watched with some envy as small companies I admired introduced their second or third product. Wouldn’t that be interesting, I thought, to start from scratch and build something unconstrained by what already exists.
My take away was always, I wish we had that luxury.
I wish our team was big enough to support multiple products. I wish we had the margin (financial, people, time) to work on something new for a few months.
Now, I see new as a necessity, not a luxury.
In the three years I’ve been at 37signals, we’ve launched three new products and are working on more. That’s in addition to constantly improving Basecamp and HEY, and maintaining multiple legacy applications, all with a team of about 60 people.
The rewards of working without the boundaries of what came before are immense. You rethink assumptions and look at everything with fresh eyes. Newfound energy drives you to try ambitious ideas and new tools.
You can move remarkably fast because you’re not constrained by customer expectations and past decisions. The team’s talents and confidence grows. The freedom is exhilarating.
And all of that happens regardless of whether or not what you ship is a huge success.
What I failed to see was that everything I described pushes your existing product forward, too. You realize that how you solved a problem in the new product is actually the very thing that had you stumped on the other one. You’re inspired to reach the same performance or accessibility bar in your existing codebase. In our case, new product development often leads to tools that we bring to our other products (and open source as well.) We regularly borrow design patterns and even features.
When you work on the same product and codebase indefinitely, it’s hard to avoid a certain kind of settling. The boundaries, caveats, and edge cases become so familiar that they limit your imagination.
Creating something new is a shortcut to reimagining what’s possible.
The product was a solid success and we were profitable when we chose to be, but not a runaway hit. We ran lean, with about 35 employees at the peak.
Eight years on a product is a long time. During those years, I watched with some envy as small companies I admired introduced their second or third product. Wouldn’t that be interesting, I thought, to start from scratch and build something unconstrained by what already exists.
My take away was always, I wish we had that luxury.
I wish our team was big enough to support multiple products. I wish we had the margin (financial, people, time) to work on something new for a few months.
Now, I see new as a necessity, not a luxury.
In the three years I’ve been at 37signals, we’ve launched three new products and are working on more. That’s in addition to constantly improving Basecamp and HEY, and maintaining multiple legacy applications, all with a team of about 60 people.
The rewards of working without the boundaries of what came before are immense. You rethink assumptions and look at everything with fresh eyes. Newfound energy drives you to try ambitious ideas and new tools.
You can move remarkably fast because you’re not constrained by customer expectations and past decisions. The team’s talents and confidence grows. The freedom is exhilarating.
And all of that happens regardless of whether or not what you ship is a huge success.
What I failed to see was that everything I described pushes your existing product forward, too. You realize that how you solved a problem in the new product is actually the very thing that had you stumped on the other one. You’re inspired to reach the same performance or accessibility bar in your existing codebase. In our case, new product development often leads to tools that we bring to our other products (and open source as well.) We regularly borrow design patterns and even features.
When you work on the same product and codebase indefinitely, it’s hard to avoid a certain kind of settling. The boundaries, caveats, and edge cases become so familiar that they limit your imagination.
Creating something new is a shortcut to reimagining what’s possible.