Agile product management tools from Roman Pichler

Recently, the team at Lucidspark had the opportunity to collaborate with Roman Pichler and recreate two of his most popular tools, the Product Vision Board and the GO Product Roadmap, as Lucidspark templates.

Before introducing those templates, I want you to know a bit about Roman and the tremendous impact he’s had on the Agile community.

Roman Pichler and Agile Scrum

In the early days of Agile, the Scrum community was anchored by a small group of committed, passionate people. That’s how I first met Roman—we were members of the same professional community and were sometimes speakers or facilitators at industry events. The Scrum community was thrilled to have Roman share his perspective and insider’s view of product management.

Roman had been one of the first Scrum practitioners at Siemens, and from that experience he contributed to our community. Roman brought new insights to the role of a Scrum Product Owner, a role that was underrepresented at the time. This is the key role that bridges the gap between the business (requester) and delivery sides of product development. 

Roman’s thought leadership guided our community to better comprehend the processes, pain points, and day-to-day work life of the Product Owner stakeholder. With this level of understanding, we created programs and materials for this critical Scrum role.

It didn’t take long before Roman established his reputation as an expert and thought leader in the Agile space. He started formalizing some of his tools (like the Product Vision Board and the GO Product Roadmap) and sharing his insights across the Agile and the Product Management communities. The entire Agile community came to know Roman in 2010, when he published Agile Product Management with Scrum: Creating Products that Customers Love.

Closing the gap between Scrum and product management

To appreciate these contributions to the Agile community, it’s important to take a step back and explore the context surrounding the workplace shifts for which Agile practitioners like Roman Pichler have always advocated. 

At the core of Agile was a desire to heal the division between the business side of organizations and the delivery side of those same companies. Simply put, before the advent of Agile, businesses were routinely managing for output over outcomes, with a singular focus on efficiency. 

The metaphor of a relay race illustrates how the work of technologists was managed. The managers focused on the runners and considered problems like: Were all the runners on the track? Which runners were ahead, which were just keeping pace, and which were lagging behind? How could runner performance be optimized and outputs increased? 

In the midst of all of this managing, we lost sight of the goal: getting the baton across the finish line. In other words, we sacrificed outcomes for output.

This product development process was burdened with handoffs, formal documents, review gates, and approvals. In attempting to communicate with so much precision, it actually became difficult to establish alignment on the key factors guiding development. 

The result of all of this documentation and review? A product that was designed and specified well apart from the individuals who would build it, and many long months before any actual development work would begin.  

The Agile Manifesto and the principles supporting it provided a much-needed intervention to this cumbersome product development process and spotlighted the importance of:

• Collaborating with and satisfying the customer 
• Iterating on an evolving, working product versus having unnecessarily comprehensive documentation before getting started
• Developer and business roles working together on a daily basis
• Responding to inevitable changes instead of resolutely marching forward in accordance with the original plan 

An Agile team led by a committed Product Owner doesn’t require a complete up-front design and a documented predictive project plan. Instead, these teams work with an iterative, incremental framework where planning and execution happen in a series of brief iterations (sprints). 

In this model, planning conversations precede the actual work by only a day or so, and the presence of a Product Owner ensures alignment as teams participate in regular verbal check-ins to gauge understanding and seek feedback on how they implement the work. Roman and other contributors were instrumental in creating the learning objectives for the first training programs for Scrum Product Owners. Those programs generated an improved awareness of how to enable this new role.

At first, the request to the business for someone to fulfill the Product Owner role was a hard sell since people in business roles were used to being hands-off and free from having any “skin in the game.” However, with the influence of people like Roman, the value of a dedicated Product Owner soon became clear.

Visual tools for Product Owners

As part of his toolkit for Product Owners and Product Managers, Roman created the Product Vision Board and GO Product Roadmap. These visuals provide a simple framework to enable a collaborative process in support of key deliverables.

The Product Vision  Board

The Product Vision Board guides early product development by asking team members to engage with key questions across five categories: vision, target group, needs, product, and business goals.

Vision

• What is your purpose for creating the product?
• What positive changes should it bring about?

Target group

• Which market or market segment does the product address?
• Who are the target customers and users?

Needs

• What problem does the product solve?
• Which benefit does it provide?

Product

• What product is it?
• What makes it stand out?
• Is it feasible to develop the product?

Business goals

• How is the product going to benefit the company?
• What are the business goals?

With each note and insight that gets added to the board, a team’s vision for their product becomes more substantial. This Lucidspark template encourages research and iteration and foregrounds the importance of developing a clear understanding of what needs to be created, rather than basing critical decisions on gut impulses.

Additionally, the Product Vision Board centers on the end-user of each product. The board’s guiding questions help teams empathize with user questions, needs, and expectations. In short, working through the process of developing a Product Vision Board results in a thorough understanding of the context and goals framing product development decisions. 

The GO Product Roadmap

Once a team has developed their Product Vision Board, it’s time to shift gears and build out Roman’s GO (Goal-oriented) Product Roadmap. This roadmap articulates how a team plans to achieve specific objectives over a defined timeframe and introduces concrete structure to a team’s project planning. Ultimately, the process of working through the GO Product Roadmap helps create accountability, define metrics, and establish a schedule. 

The GO Product Roadmap is built for collaboration. Originally, teams would print a poster-size version of the roadmap, stick it to a conference room wall, and work together to cover the roadmap in sticky notes and ideas. Someone would snap a photo of the finished product and then digitize the roadmap to share across the company. 

With virtual whiteboards like Lucidspark, teams can now work together in real time on a shared roadmap that comes with all of the digital sticky notes and feedback tools necessary to engage in effective collaborative planning. 

Rather than focusing on the details and merits of isolated product features, the GO Product Roadmap asks teams to organize their planning around key goals and objectives. This enhances the likelihood that resulting plans will align with strategic objectives and get buy-in from executive leadership.

Embracing the iterative nature of Agile

Product management tools like the Product Vision Board and the GO Product Roadmap facilitate the collaboration and ideation at the heart of Agile. 

With Agile, teams start with a minimum viable product and release that to the market. Think of it in terms of the evolution of personal transportation. Henrik Kniberg, another early member of the Scrum community, famously explained the concept by suggesting a minimum viable product for personal transportation might be a skateboard. Over time, an Agile team collects user feedback and makes enhancements to that skateboard. Learning from building the early increments, the team enhances their “skateboard” into a scooter, then a motorbike and finally, to a fully-featured car. 

Agile helped us all get more comfortable with ideating once something testable is out in the world rather than building the whole thing and then releasing it as a finished product. This iterative approach allows for better response and feedback cycles with users. The product that results is built on a strong foundation of real-world user experience. 

While it might seem counterintuitive to release a mere skeleton of what a team hopes their product will someday be, the exceptionally responsive development process translates into a much better finished product in the end. 

Thanks to innovators like Roman Pichler, product management and, more specifically, the role of the Product Owner are now central to Agile, and more specifically to Scrum. And teams and organizations are better off for it.