In the following exchange, Released’s co-founder, Jens Schumacher (@jensschumacher), draws on his years of leading products such as Jira and Bitbucket to offer a unique framing for understanding niches, dev-first software, and scaling better.
— Starting out after 17 years of product leadership
— Five heuristics for niches (and how Atlassian started in one)
— Pursuing sequential growth with laddering
— Building for developers and adjacent roles at once
— Selling dev tools (then and now)
Starting out after 17 years of product leadership
Why now and why this particular idea?
After leaving Atlassian (having spent 15+ years there), I joined a search startup called Search.io. In my role as Chief Product Officer at a small company, I was the one responsible for communicating product improvements to our customers.
And frankly, amidst the whirlwind of startup responsibilities, maintaining clear and consistent communication with our users was a challenge.
I searched for a tool to help me write and publish release notes. I found dozens. I tried them all. Most did a decent job of publishing, but none helped me with the hardest part: writing the release notes.
I ended up writing a Jira integration that would publish completed tickets to the website. It was pretty simple, but it worked for me.
After Search.io was acquired by Algolia, I chose not to join them. Starting my own company had always been on my bucket list. The acquisition presented the perfect opportunity for me to take the hacky solution I had built for myself and turn it into an actual product.
Five heuristics for niches (and how Atlassian began in one)
It’s worth noting that Atlassian also started in a niche.
Jira began as a tool for developers to track tasks and bugs.
We deeply understood the developer’s world and crafted a solution that resonated with that audience. Over time, we expanded to different markets and personas, but our roots in that niche gave us a solid foundation to build upon.
A niche isn’t just about catering to a small segment of the market.
It’s about deeply understanding a specific problem and tailoring a solution that addresses it in the best possible way. It is about recognizing that while you can’t be everything to everyone, you can be the absolute best for someone.
Validating a niche’s potential for expansion is a blend of art, science, and a bit of gut instinct.
Here’s how I approach it:
1) Deep dive into the problem:
You need to ensure you’re solving a genuine problem, marked by repeated complaints from diverse customer groups. The deeper and more painful the problem, the more likely there’s room for growth. If you’re addressing a surface-level issue, the niche might be too shallow.
For Released, it started with my own painful experience of writing release notes, and frankly not being able to do it as consistently as I should have. When talking to other product managers and founders, that pain point quickly emerged as a pattern.
2) Engage with your users:
Your users are a goldmine of information. Engage with them regularly. Understand their pain points, workflows, and what other tools they use. They’ll often lead you to areas of potential expansion you hadn’t considered.
3) Look for adjacent needs:
Once you’ve identified and addressed a specific problem, look around it. Are there adjacent problems or needs that your solution could naturally extend to? Look for unexpected ways or hacks with which your customers solved a problem or processes that are extremely inefficient.
4) Market Size and Trends:
While niches are, by definition, smaller segments, it’s essential to gauge the overall market size. Is the niche growing? Are there emerging trends that could make it more relevant in the future?
In the case of release notes, aside from the continuous growth of the software industry, more and more teams are looking to better communicate their progress and plans with their customers.
Right now, great customer communication is still a differentiator, but, in the future, customers will expect better communication from every company.
5) Competitive Landscape:
A niche with no competition might sound ideal, but it could also indicate a lack of demand. On the other hand, a niche with some competition suggests there’s a market, but you’ll need to differentiate yourself.
While expansion is a worthy goal, it’s essential to ensure you’re serving your niche effectively first. Once you’ve established a strong foothold, the paths to broader horizons often become clearer.
When I joined Search.io, we were spread thin, trying to cater to a vast market: from websites to real estate, commerce, and accounting search.
It was overwhelming for a company our size.
We decided to take a step back.
Website search was making up 90% of our business.
But it was a competitive market with little differentiation.
If your website search is 10% better than someone else’s, does it really make a difference? In most cases people won’t even be able to tell. For many of these customers, search was a “checkbox feature” that just needed to be good enough.
Nevertheless, we observed that the same 10% improvement had significant potential for ecommerce customers. For example, we increased the conversion rates of a major retail client by over 10%, translating to millions of dollars in additional revenue.
Not only is that an easier sell, but also a much harder problem to solve, meaning less competition. So, while website search remained our bread and butter, we channeled our entire company’s energy towards e-commerce.
Operationally, we shifted 90% of our engineering resources; and sales and marketing shifted slower as we built out more and more capabilities for e-commerce.
With Released, it feels like we’re coming full circle on the concept of niches. No matter how comprehensive a product aims to be, it can’t possibly cater to every nuanced demand.
Atlassian’s focus is on teams and team collaboration. Customer communication, from a product perspective, is an afterthought. That’s where Released comes in to fill the gap.
First by generating release notes based on the team’s Jira tickets and ultimately by empowering teams to deliver exceptional customer communication.
Pursuing sequential growth with laddering
Laddering (I’ve written about it, here) has been instrumental in shaping our strategy at Released. It was clear from the beginning that release notes are just a stepping stone, not our final destination.
Our true north has always been to empower teams to deliver exceptional customer communication. While release notes are a part of that, our vision extends far beyond, aiming to redefine how teams connect with their users.
(The three broad phases of laddering)
The concept of laddering emphasizes building on foundational strengths and then reaching for the next rung. For us, it means starting with release notes, perfecting it, and then identifying the next logical step.
Instead of chasing every opportunity, we are focusing on sequential growth, ensuring we reach our goals before moving to the next step.
At Released, that foundational strength is a mix of a core customer base and a technology platform upon which we can build the next communication solution for our customers.
This approach not only streamlines our priorities but also fosters a culture of continuous improvement and strategic progression.
Also, I don’t think laddering necessarily helps you with product market fit. But you certainly want to find it as part of your first step, otherwise there is no point going further up the ladder.
Building for developers and adjacent roles at once
Developers, by nature, gravitate towards tools with depth.
They seek out feature-rich tools, crave customization, and are willing to navigate a steeper learning curve for the sake of flexibility.
On the other hand, wider technical teams prioritize breadth in tools.
They value solutions that seamlessly integrate into their existing tech stack and come with intuitive interfaces. In essence, while developers demand depth and precision, broader teams emphasize usability and cohesion
Jira, in many ways, embodies the challenge of serving two masters. For developers, it’s a sandbox of possibilities. Its malleability allows them to tweak, adjust, and mold it to fit their unique workflows. And every single team’s workflow is slightly different.
But Jira’s audience doesn’t stop at developers.
It extends to project managers, business analysts, and other less-technical stakeholders. For them, the tool needs to be more than just flexible; it needs to be intuitive, straightforward, and ready to use without a steep learning curve.
So, the real challenge?
Crafting Jira in a way that it remains the go-to tool for developers craving depth, while also being the reliable, user-friendly platform for a broader audience.
And this is different from the typical, B2B user/buyer divide, since Jira is already in the organization at that point. That’s the beauty of the Atlassian model. You get in with one department and spread to others.
Building a community of champions has been extremely valuable to bridge the gap to other functions. It’s hard to influence that from the outside with sales and marketing. You need someone on the inside who can advocate for the tool, educate people and drive adoption.
Here’s another major, inventive Atlassian effort along these lines. When I came on board in 2004, the blueprint for an expansive ecosystem was already in place, thanks to the existing extension points in our products.
Those early days saw passionate developers stepping up, creating free extensions to enhance our core offerings.
As discussed above, catering to a developer audience is a unique challenge; they seek extreme flexibility. Even if a product could address all those needs, it would be a complex, unusable mess.
This is where an ecosystem is so important. It provides that sought-after adaptability, allowing developers to mold the tool to their requirements, while the core product remains focused and efficient.
Selling dev tools (then and now)
Developer-focused products, like those from Atlassian, exemplify the power of product-led growth, perhaps more than any other category. Developers, by nature, don’t appreciate a hard sell. Instead, they gravitate towards tools that genuinely enhance their workflow.
Addressing their specific pain points and offering an intuitive user experience is key. When a product seamlessly integrates into a developer’s routine, it’s not just adopted; it’s championed.
The beauty of catering to developers is the organic virality. Developers prefer discovering tools through peers or their own research rather than through aggressive sales pitches.
By iterating based on their feedback and fostering a community around the product, you’re not just refining the tool; you’re building trust and loyalty. In the realm of developer tools, a well-crafted product doesn’t just lead to growth; it becomes an industry standard.
While I’ve always been a proponent of products that sell themselves, the downturn highlights the importance of a balanced approach. It’s not about abandoning PLG, but rather complementing it with a more proactive sales strategy.
Developers and tech teams still prefer products that seamlessly fit into their workflows, but in tighter markets, waiting for organic discovery might not be enough.
This doesn’t mean we should revert to aggressive sales tactics.
Instead, it’s about thoughtful outreach, understanding potential clients’ pain points, and demonstrating clear value. It’s about building relationships, offering solutions, and being there for customers when they need it most.
Related reading from the Relay archives:
— Rodeo’s co-founder, Ben Fisher, on building for uncomfortably narrow niches
— Crossbeam’s co-founder, Bob Moore, on an analogy for niching down and PMF
— Onboardbase’s founder, Dante Lex, on the challenges of selling to engineering leaders
— Typesense’s co-founder, Jason Bosco, on why open source is an ideal bet for dev tools