Now, Next, and Later: Transforming the Roadmap
Bolstra had no shared, reliable source of truth for what we were actively pursuing or what we would pursue later down the road. We had expectations concerning the product to spare, but no single reference of priority or direction.
Cliffnotes
🏢 Organization
Bolstra, a B2b SaaS startup providing a web-app empowering Customer Success teams to manage their work, standardize & automate processes, and scale their account strategy.
📁 My Role
Product Manager, User Researcher
🙋 Stakeholders
Executive team, Cross-functional leads, Existing userbase and prospective customers
⏱️ Duration
About two months
✔️ Key Results
New Roadmap, Outcome centricity, Increased alignment
Background
Bolstra's product had been outsourced to and built by a shared expense R&D firm called NorthQuad, which also acted as the product division of another local company, Lumavate. About a year into their relationship, NorthQuad had built a product of somewhat remarkable complexity given the short period Bolstra had been operating. The decisions that made it up had been decided mostly through back-and-forths between NorthQuad and the Bolstra sales team. By responding to pressures from the pre-sales process, they had been able to churn out new functionality very rapidly and begin to gain sales traction.
As time went on, the shared-expense model that Bolstra, NorthQuad, and Lumavate had been navigating became less tenable. Lumavate was growing fast and negotiating for more of NorthQuad's resources. Eventually, it was decided that NorthQuad would be merged into Bolstra and Lumavate (mainly the latter), but unfortunately not before development for Bolstra had slowed to a crawl in the final few months.
Problem & Opportunity
The rapid feature-building operation that had kicked off Bolstra's product was now far more hindrance than a help. Attempts to continue under that same paradigm in the last six months of working with NorthQuad had resulted in waterfall-like projects that never seemed to end, often ballooning from scope-creep.
As I came onboard at Bolstra full-time, following the dissolving of NorthQuad, one of the first meetings I had was with our Customer Success (CS) team. They wanted to walk through the Trello board that had originally managed NorthQuad's feature factory in the first year of the company. One of the Customer Success Managers (CSMs) jokingly told me,
"What we have here is probably a good six years of development work."
They probably weren't far off the mark on that estimate. There were hundreds of cards, some still relevant ideas, some already addressed, and nearly all abandoned for at least a year. Equal parts amusing and distressing was the "Need Now" list, full to the brim of cards and due dates that had long since passed.
As I was starting full-time at Bolstra, so was our new in-house development team. A CTO, a senior developer, and our integrations engineer. We had a lot to do to remain competitive and recover from months of slowdown. Even more to do if we wanted to see significant growth.
That Trello board wasn't going to be our roadmap. So what would be? A common artifact at Bolstra was the Customer enhancement request Google Sheet. These at least were kept relatively up to date, but they suffered from a similar problem as the Trello board did. Both were essentially backlogs, not roadmaps. Features to delivered, not a strategy to be executed, not problems to solve, and not outcomes to achieve. Using a backlog as a roadmap wasn't going to mesh well with the user research practice I'd worked to institute for Bolstra, and was still striving to mature and grow.
Approach
Step 1: Stakeholder Alignment
One of the first projects I'd taken on after joining Bolstra full-time was a survey of our user base centered around gauging sentiment toward our product. What were we serving up that was useful? What wasn't hitting the mark? I suspected we had far more work to do in making what we already did more valuable, that the current product wasn't doing just fine as it was. That it would need to be improved alongside new functionality being added. My suspicion was proven to be largely correct by the survey. I looked at it more as lead-generation for more in-depth research than as being directly actionable in its own right, but there was one exception to that. The results served as a stakeholder wakeup call to some of the shortcomings of our product. It was a clear indication that the methodologies that had gotten us to this point hadn't necessarily worked as well as they were thought to have. Aligned around that, a conversation about next steps was possible.
Step 2: My Proposal
Traditionally Bolstra had been uncomfortably close to being inside of what Melissa Perri terms, "The Build Trap"—Being stuck in loops where output gets prioritized over outcome. It seemed the perfect situation to take a leaf out of her book and create an outcome-centric roadmap. We would frame roadmap items as outcomes we wanted to achieve. To avoid the temptation of leaning back into prioritizing outputs, we organized roadmap items not on a hard timeline but in the categories, Now in development, Next, and Later (6+ months). Items were to be worked on until they were achieved to a genuinely impactful extent as opposed to being crammed into a particular timeframe no matter their readiness.
Step 3: Targeting Outcomes
Alongside my efforts to implement this new kind of roadmap, we were working as a company to establish a far more focused marketing and sales approach. Many a workshop had produced vision and mission statements, not to mention all the packaging and positioning detail that backed them up.
Bolstra's vision was to "Bolster customer advocacy by curating knowledge, facilitating collaboration, and inspiring action.". Our mission one to "...help B2B companies bolster Customer Success and realize customer advocacy.".
Our criteria for landing upon outcomes became:
✓ Is the outcome aligned with Bolstra's vision and mission?
✓ Does the outcome allow for improving current functions of Bolstra as well as adding new ones?
✓ Is the outcome centered around a problem that seriously impacts our users?
Impacts
- The roadmap itself. A single artifact to align around that would represent priority, problem spaces, and product direction.
- The roadmap served not only as a useful artifact for the product team but also enabled other stakeholders such as those in Sales or Customer Success to have more substantive, generative conversations with users.
- Outcome centricity (rather than feature-centricity) proved to be a frame that allowed the product team more latitude to investigate problem spaces, ideate, test, and ensure the effectiveness of solutions.
- Roadmap items came to act as convenient top-level umbrellas for more granular internal activity supplemental to the roadmap. e.g., Release notes or sprint planning.
Final Thoughts & Related Work
As with any project, the first delivered iteration wasn't the end of the project. While the areas we had chosen to target didn't shift much over the next year of the roadmap's use, the writing that conveyed those targeted items did. Every conversation with a stakeholder of the product, be they a member of our team or a user, was an opportunity to refine the messaging or clarity and was certainly taken advantage of.
Early conversations around the roadmap worked when it came to generating productive discussion around our overarching strategy, but its form at that point wasn't particularly self-supporting. The roadmap had to be presented by somebody who knew a lot about the topics therein. As I refined it, the roadmap grew into an artifact that was more self-explanatory — cutting out time spent explaining what roadmap items meant allowed us to go deeper on the generative research opportunities that roadmap discussions afford.
The first roadmap item we saw through to completion was, "Increase the actionability of cross-account dashboards and reduce the frequency of having to enter an Account page to manage it.". One of our wordier ones, but directly tied to problems in one of the primary areas of our product. The Accounts List and associated Accounts Dashboard weren't particularly efficient at doing what they were meant to do, surfacing critical information in easy to consume ways.
Want a look into the first release to address that roadmap item? One that also acted as the kick-off for our new agile release cycle and set a precedent for the use of release notes to support onboarding and adoption for interactions and product areas that came with them.