There is a fundamental tension in product development between going wide or narrow. Ultimately, reaching a large market is necessary for creating substantial business success. But if you immediately strive to create a product for too many people, you risk creating something for nobody.
In his 2012 post How to Get Startup Ideas, Paul Graham argues that you should focus first on users who will want your product to the extent that “… they’ll use it even when it’s a crappy version one made by a two-person startup they’ve never heard of…” More commonly, Graham says, successful startups start narrow, like a deep well.
Rob Go expresses the “start narrow” sentiment in his recent post, The Niche Pitch. When faced with feedback that your company needs to address a larger market, Go says you should “… do the opposite. Become even more focused, more obsessed with the one thing that will make your product really really great, and the specific types of people who will absolutely love you for it.”
The most extreme incarnation of a narrow focus is building a product first for yourself. For example, Slack spent months building a messaging app for their own team before inviting other companies to use it. “Eating your own dog food” tells you what’s actually important in your product.
Building a product for a narrow audience, with the ambition to scale later, is a leap of faith. It may have been predictable that if Facebook went viral at Harvard, it would work for other colleges. But not all products have a clear path to scale.
Similarly, building something you love does not imply other people will. In his 2010 post, 1.0 Is the Loneliest Number, Matt Mullenweg writes:
Usage is like oxygen for ideas. You can never fully anticipate how an audience is going to react to something you’ve created until it’s out there. That means every moment you’re working on something without it being in the public it’s actually dying, deprived of the oxygen of the real world.
The “Release early, release often” philosophy is taken almost as a given amongst agile product teams. While releasing early may lead to shipping products with known flaws and limitations, the approach can be the shortest path to achieving the best product. Usage helps you find issues and teaches you how to prioritize enhancements. Testing your product with real users can tell you that your product was based on a false assumption, giving you the opportunity to change course before investing more in the wrong direction.
The dictums “start narrow” and “usage is like oxygen for ideas” are often compatible. The correct approach for your product may to be to release early, but only within the narrow target audience.
But, the two sentiments can conflict. If you are starting by making a product for yourself or your own company, it may not be trivial to get others, even in your narrow audience, to use it. Making a product that users love is different than making a product that people will use. Just because somebody would love a product if they used it doesn’t imply they will be willing to try it or get over the hump of unlocking the value. When you’re making a product for yourself, presumably you don’t have to convince yourself to start or keep using it. If you’re making a product for others, in contrast, you have to spend energy creating a clear upfront value proposition and stickiness mechanisms to drive continued usage.
This leads to a strategic question:
If you’re building a product first for yourself, how far do you push it before spending the effort to get other people in your niche to use it?
For a startup with limited resources, the question is significant because you may invest heavily going down one of the two paths only to hit a dead end at the next phase. That is, you could burn your energy creating a product you love that no one else is willing to try. Or, you could crack the formula for driving demand before knowing whether you can deliver on the promise.
I’m facing this dilemma with my side project, Double-Loop.
Double-Loop records a history of your past product launches for the purpose of organizational memory and learning. My hypotheses is that you will make better products if you (1) record a clear objective and expected impact of each launch, (2) loop back to previous launches to record the results compared to expected outcomes, and (3) allow all team members to read and author the history of your product.
Double-Loop has been developed to the point where the primary behaviors are now possible in the app. My company, a digital healthcare startup, has used Double-Loop to create a timeline of product events going back to September of last year. This has proven valuable: Double-Loop has helped us be more methodical in our product approach, connect changes in our metrics to deployments, and communicate our impact to the broader company.
While there is clear utility in the current version of the app, there’s a lot more to be done to perfect the tool for my company’s use. For example, Double-Loop could integrate with web analytics services to contextualize the launch timeline. And Double-Loop could be enhanced with a streamlined tool for taking and annotating screenshots of each launch.
This is option A. I could continue iterating on Double-Loop purely to solve the needs of my company.
But my goal with Double-Loop is not only to create a great tool for my company. I want to transform how all software companies think about their product development process. For this reason, in the spirt of “Usage is like oxygen for ideas,” I’ve recently opened Double-Loop for other companies to use. I published a post, Double-Loop 1.0, that explains the vision and invites early users. About 5% of readers signed up so far.
It’s too early to tell if the first group of companies trying Double-Loop will use it long enough to unlock the value of creating a product history. I speculate that many of them won’t. The pay-off is small for creating one or two events in the system. The true benefit emerges only after you’ve recorded a timeline that extends beyond your active memory. Even for me, when Double-Loop was first ready to use, I had to push myself to add events until the benefits started to accumulate.
It’s difficult to grow a product that requires a new behavior, like consistently recording your product history. It’s doubly difficult when the new behavior comes with a delayed reward. The habit loop breaks down.
With Double-Loop, I have ideas for solving this stickiness problem.
- Double-Loop could integrate with teams’ deployment processes such that events are automatically created with each deploy. These auto events could be pre-populated with project management tasks and code commits. My hypothesis is that companies will be more likely to unlock Double-Loop’s value if the effort creating a product history is dramatically reduced.
- Double-Loop could integrate with Slack such that each new event in Double-Loop triggers a notification. A Double-Loop bot could remind you to loop back to capture the results of launches that happened previously. These features would help Double-Loop spread within a company and nudge continued usage.
Pursuing this direction is option B. I could focus on enhancing Double-Loop in a manner that increases the likelihood that other companies will unlock it’s value.
So which path should I take, option A or B? Should I keep making Double-Loop great for my company or should I try to get others using the product, even before it is great?
If you’d like to go on this journey with me and help craft the future of Double-Loop, signup below.
Product Logic 