It’s Time for Product Success

“What got us here won’t get us there.”

It’s one of my favorite quotes. And it’s certainly never been truer in the world of product building than it is today.

Over the past two years we’ve had hundreds of conversations with product teams—of all sizes and in every industry. The learnings and outcomes of these conversations have been enlightening, they’ve also largely driven our vision and strategy for LaunchNotes.

To summarize what we’ve seen and heard, product teams are at an inflection point. They’re under more pressure than ever before and the current situation is, frankly, unsustainable.

Ask yourself if you’ve felt, or seen, what we have:

• Product managers who are stretched thin and burning out
• Product KPIs that feel harder, or even impossible, to achieve
• A growing feeling of vague or unreasonable expectations from executives
• Increasing pressure on product orgs to drive attributable revenue

Worst of all: a general feeling amongst product teams of treading water and making less and less meaningful progress, despite thousands of completed sprints and ticked-off roadmap items.

But big challenges create big opportunities. And over the past two years we’ve also gotten to know teams – many of whom are our customers – who are facing these challenges head on, forging a new path forward, and finding innovative ways to excel and thrive as the industry transforms.

In that spirit, we wanted to take the opportunity of our Series A announcement to share our thoughts on the current state of the software industry, and specifically what these trends mean for the future of product development, the future of LaunchNotes, and the era of Product Success.

The product development cycle needs an upgrade

Every product team, whether they build cars or B2B SaaS software, utilizes a product development cycle. The details can be debated and presented in different ways. But it is, essentially, some version of this: plan, build, launch, collect feedback.

• Plan: Products and improvements are ideated, prioritized, and approved
• Build: Plans are specced out and development is done
• Launch: Products are shipped and changes are communicated to customers
• Collect feedback: Feedback is generated and shared back with the product team

High performing product teams create a tight, closed-loop system in which each of these four stages naturally powers the next.

But every product team and product manager we know—even the very best ones—are struggling with some (or all) of these steps. They don’t feel the momentum they should. As one PM told us, “I feel like I’m always pushing multiple boulders up the hill at the same time.”

Instead of each step benefitting from the momentum from the last step, each step feels like a cold start. The obvious question is: why?

There’s no doubt product management is one of the most challenging jobs in any software organization. But that’s always been the case. Right now it’s different. There’s something else going on.

We’ve studied this space from every angle and found that there are fundamental issues with the traditional ways of running development cycles in an environment that is anything but traditional.

Cracks forming under the surface

We’ll start by calling out the elephant in the room: For many product teams this development cycle actually hasn’t been working like a well oiled machine for quite some time. And while lots of band-aids have been applied over the years, optimizing a process using outdated tools and practices can only get you so far.

The bottom line is that the speed at which engineering teams can build and ship new software has grown exponentially over the past decade, and the rate at which product teams can build and manage a product development cycle to support this work has not. This has created a massive, and growing, amount of friction in the product development cycle.

But it’s hardly the only underlying issue.

Think of the way software used to be built and delivered: developers worked for months on that year’s “big release.” When it was ready, a laundry list of updates and improvements got thrown over to the customers, who then made the decision to install the updates on their own servers.

Now consider the way software is built and delivered today:

• Agile & CI/CD: Developers ship multiple times per day.
• SaaS: Vendors ship changes to customers’ accounts instantly, often without the customer even knowing.

The perfect storm: the last two years have led to a tipping point for product teams

I know what you’re probably thinking: SaaS and Agile software development are more than 20 years old. And DevOps has been around for a decade. These underlying trends may be accelerating, but they’re not new. So what’s causing an inflection point right now?

The rise of self-serve and product-led everything

Arguably the biggest trend in software over the past five years has been product-led growth. It seems like every executive, thought leader, and investor across the industry suddenly wants products that sell themselves.

And why wouldn’t they? A move from software that’s sold by humans to software that sells itself is attractive for a lot of reasons, especially through the lens of a business’ P&L.

But if you ask the people in the trenches building software every day, you’ll get a different story. At a time when cracks were already forming under the surface, PLG added an extra layer of pressure on product teams everywhere to deliver superior products at an even faster clip.

As if PMs weren’t feeling like they were juggling enough balls already, suddenly selling (or, more accurately, building a product that sells itself) became yet another skill they were expected to master.

Then came March 2020.‍‍

‍

The shift to remote and asynchronous work

With all these fast-moving changes, things were already challenging prior to COVID-19. But a hard-working product team could power through and pull it off. Throw in a two year global pandemic and a shotgun wedding with remote work? Forget about it.

This overnight shift was the straw that broke the camel’s back. It left product teams everywhere, suddenly, with nothing more than Slack, Zoom, and Jira to keep contact with the people they need to collaborate with daily. As time went on, it became less and less likely that these colleagues even shared the same time zone.

The traditional ways of running product development are broken in today’s environment

All these converging realities are making painfully apparent what many product leaders have been experiencing for years: The traditional ways of executing product development haven’t adapted to the new normal. And what were once cracks under the surface have become full-blown chasms.

Here are the four areas where product development is most broken.

Launch: Most product launch strategies were built for waterfall releases

Despite the steadily increasing rate of code production and deployment using CI/CD, the majority of companies are still communicating about these product updates on a monthly or quarterly cadence. Simply put, this disconnect has become a massive round peg in a square hole.

When a product is being improved and updated as often as daily or weekly, but customers only learn about these changes monthly or quarterly, it creates enormous frustration for customers, and the people who need to support them.

Ironically, many companies try to solve this by adding more engineers and more feature work. And you can’t really blame them. This is the logical response when product teams are asked to ship more value faster.

However, it’s counterintuitive to build and ship value continuously unless you also have an effective way to get it into the customers’ hands. And as such, it’s no surprise that there’s a wide and growing gap between the build and launch phases of the product development cycle.

Feedback: Traditional feedback collection methods aren’t targeted, granular, or fast enough

Most product teams will tell you they have some product-level feedback (often in-app NPS survey), occasional feature level feedback, and essentially no feedback at the individual change level. So we’ve created an environment where a lot of changes are being shipped, and “what was the impact of that change” is a very hard question to answer.

It’s nearly impossible for product teams to discern which improvement may (or may not) have moved the needle on any of their priority metrics.

More robust feedback efforts can help with this, but they often involve large customer research initiatives whose results take months to get back into the hands of product teams. Yet another example of a practice that works well if you ship once or twice a year, but that’s misaligned with today’s reality.

Planning: The majority of product planning and ideation is a one way street, disconnected from relevant stakeholders

In an effective planning cycle, the entire roadmapping process is treated as a multiplayer game involving deep connections with users and relevant stakeholders. This includes those who may have provided feedback, but also includes anyone for whom the current set of engineering work is focused on helping. Imagine these scenarios:

• Being able to instantly reach out to individuals who left specific feedback.
• Quickly running wireframes by key stakeholders for feedback
• Knowing exactly who would be perfect to enroll in beta programs.

Those are just a few benefits. The planning and ideation process thrives when it’s a two-way street.

But it’s not the reality for so many product teams today, even those with the best intentions and thousands of feedback items at their disposal. The vast majority of their roadmapping process ends up occurring in a vacuum.‍

Building a product roadmap and then having no way to continuously and securely validate it with customers means a product team’s work is being hidden from the very users for whom the roadmap exists in the first place. And it greatly increases the risk the work may actually miss the mark entirely.

If the ultimate goal of a healthy product development cycle is to deliver for your customers and the market with speed and accuracy, there’s no greater roadblock to this effort than a planning process that’s disconnected from the stakeholders and feedback that matter most. Yet another chasm at play.

Build: The development process leaves non-technical teams in the dark, and product managers playing project manager

The old stereotype that product managers are glorified project managers is, frankly, insulting to both of these roles. But the sad fact is, too many product managers feel like most of their time is eaten up doing project management tasks: checking statuses, assigning tasks, moving dates and labels around, and responding to “hey, can I get an update on this?” messages on Slack.

And, on top of everything else they’re responsible for, keeping the overall organization (specifically all customer-facing teams) up-to-date on each project is one of the biggest factors burning out PMs today.

From what we’ve seen and heard, most organizations are trying to solve this problem in one of two ways: Either buying additional seats to products like Jira and GitHub so every member of the org can log in and follow along themselves and/or adopting some new system of asynchronous status updating. The issue is that neither of these solutions actually make the product manager’s life any easier, or the product org any more successful.

Both of these strategies are band-aids and rife with issues of their own:

• Non-technical teams have no interest in using developer tools and thus rarely do
• 95% of status updates lack the correct level of context to be helpful to the consumer
• 30 seconds after any status update is posted it’s usually out of date (but no one knows for sure)
• Status update feeds almost immediately become noise and thus everyone tunes out

The end result? Individuals who need to ensure they’re getting the latest and greatest information simply revert to the only source they know they can trust: the product manager.

As we think about the product development loop, there’s no doubt that the chasm between the build and launch phases is in large part the result of an inability to keep the rest of an organization coordinated and aligned with the product development process in a way that’s personalized, relevant, automated, and doesn’t make the product manager the sole person holding it all together.

The solution: Modernizing the product development cycle with Product Success

A Product Success Platform connects the core parts of the development flywheel—comms, feedback, and planning—into one platform. Advancing and accelerating the product teams of today, so they can be even more successful building the technologies of tomorrow.‍

Repair the breakage between steps and turn your product development cycle into a self-propelling flywheel

At LaunchNotes we are modernizing the individual steps of the product development cycle and tying them all together on one seamless platform.

• Launch: Modern changelogs—both for internal and external use—enable product teams to continuously communicate updates and changes to the right stakeholders at the right time through any number of mediums that can be fully customized by each subscriber.
• ‍Feedback: A full range of feedback capabilities allow product teams to not only collect contextual feedback through many different touchpoints, but also intelligently track who provided each piece of feedback and how it maps to both the product roadmap as well as related announcements.
• Plan: Advanced roadmap functionality and related access controls unlock product teams’ ability to provide every relevant stakeholder–from end users to enterprise customers to key executives–the ability to see, follow, engage with, and leave feedback on secure product roadmaps.‍
• Build: An entire suite of tools and integrations will remove product management as the go-between and enable organizations to effortlessly stay coordinated and aligned throughout the product development cycle in a way that’s personalized, automated, and secure for each subscriber.

Individually, each of these capabilities is an important piece of a product team’s toolkit, and with LaunchNotes you can use any one of these completely on their own. But the real magic happens when you close the loop and bring each of these activities onto a single platform.

The energy from each step transfers more and more seamlessly to the next. That’s the definition of momentum. Now, instead of starting each step from a cold start, data and insights flow from one step to the next and create effortless inertia.

What this ultimately creates is a product development process that feels like an energy-efficient flywheel, with less and less manual effort required to keep the cycle running.

In a fully-remote world of product-led everything, having your product development cycle working at maximum efficiency is the ultimate superpower for your product team and business.

Once this flywheel gets humming, some pretty incredible things can start to happen:

• Product teams feel re-energized and excited to come to work every day.
• Customers feel like they’re being heard and have a real seat at the table.
• Product leaders feel like they’re back in the driver's seat, setting strategy and getting results. 
• Product traction takes off in a real, unmistakable way.

Join the Product Success movement

We’re excited about how far we’ve come and the ability to start driving Product Success with LaunchNotes today. We’re even more excited to see our customers and partners achieve the success they deserve.

We can’t wait to share what we’re building with you and hear what you think. Join our free Slack community, LaunchAwesome, to stay in touch.

If you want to be part of the journey, start a free LaunchNotes trial today or schedule a 1-1 demo.