What Does the Shift From Project to Product Really Look Like?

Following last year's launch of Dr. Mik Kersten’s best-selling book "Project to Product", the movement continues to gather serious momentum, with 55% of organizations surveyed by Gartner looking to move to a product-centric mentality. What does a transition from project to the product really look like?

While my company Tasktop isn’t a 30,000-person enterprise, much of what we have experienced is still applicable to large scale organizations. We’ve also learned a lot through our work with enterprise customers, over 40 percent of whom are in the Fortune 100.

Being a smaller company means that as VP of Product Development, I have strong visibility into finance, HR and all other key departments that underpin the business. This insight enables me to paint a much clearer picture of the cross-organizational challenges in store — and how to address them.

Curiously, even though we’re a product company (not a bank or insurance company with a complex portfolio of products and services), we still faced project-based issues that were causing pain across the organization. On the surface, we were hitting all the right notes, addressing the seven core areas that underpin the shift to a product-centric mentality:

1. Budgeting: Funding allocated based on business outputs, with new money allocated as and when needed and based on the delivery of incremental results.
2. Timeframe: No defined end-date — focused on the multiyear lifecycle of product including ongoing maintenance and health activities.
3. Success: Evaluated according to a team’s ability to deliver incremental value and meet business objectives.
4. Team: Cross-functional teams dedicated to a specific product value stream for stability and labor resource.
5. Prioritization: Products guided by road maps and hypothesis testing, laid out by product owners and their business counterpart, emphasis on feature and business value delivery.
6. Visibility: Easily mapped development directly to business outcomes for better transparency.
7. Risk: Spread out across long timeframe and multiple iterations, creating opportunities to adjust product features if the initial assumption was incorrect or strategic opportunities arose.

Yet we still diagnosed symptoms that were indicative of a technology organization that wasn’t completely product-centric. These areas included:

• Us vs. them mentality between product and engineering.
• Problems had to go high up (CEO) to be resolved.
• Incomplete knowledge about and empathy for our customers.
• Felt more inward-focused; risked losing sight of the customer.
• Not truly product-focused across the organization (through finance, HR, biz dev, etc.).
• Investment decisions were “twice-baked”; they had to resell to engineering.

Digging deeper, we realized that mindset is everything and that the context of the work was critical to ensure we were focused on what matters at the end of the day: the customer. We sought to alleviate these symptoms by looking through the lens of the customer to make sure we were truly customer-obsessed.

Structuring Around the Customer

One of the key changes we made to become more customer-centric was put a stop to the “us vs. them” mentality between engineering and product.

This structure meant teams only had a view of their own area of work — despite working on the same product. The “aha” moment was the realization that our teams were not structured in the way a customer views us. They only saw products and features, not the two teams that collaborate to deliver it.

Worse still, the disconnect between the two departments meant it was hard to establish consensus, meaning crucial business decisions often had to be resolved by our CEO. Much of this discourse stemmed from the fact that we were functioning as two teams (engineering and product) instead of a single delivery-oriented team.

Many of the problems and problematic dependencies that we saw were symptomatic of a siloed organization, with hierarchical thinking and behavior. To fix this, we restructured the engineering and product departments in a way that mirrors how customers see our product.

We realized that we had to embody the notion of “customer first” by thinking and organizing from their perspective. We decided to align the organizational chart not to specializations (e.g., engineering, product, cloud operations) but to four product value streams. As part of this restructure, we created a significant new role — a product value stream lead (PVS lead).

Introducing The Product Value Stream Lead

With the engineering and product teams merging into a single development team to work across four product value streams (two internal, two externals), we needed somebody to spearhead those product value streams. Spearheading them is very different from being a product manager.

We devoted a lot of time to outline the difference between a PVS lead and product manager. You need both roles and neither are project managers; this distinction had to be clear to those in the roles and in our communications across the business.

A PVS lead is responsible for all aspects of their product value streams in terms of:

• Business: Vision, design, customer happiness, costs, pricing, market changes.
• Operational: Processes (both engineering and product), licensing, etc.
• Technical: Agile teams, estimation, architecture.

In the top-level default structure, the PVS lead would typically sit above the engineering manager and product manager in their respective product value stream. Within this structure, a PVS lead draws from the expertise from both disciplines and then makes informed decisions that strike a balance to best serve the customer.

What’s the Difference Between a Product Value Stream Lead and Product Manager? and What Makes a Great One?

Business-oriented: A great PVS lead is business-minded. The role combines product management, design and technical execution with a business lens through all lifecycle phases.

Empathetic: All product value streams comprise an eclectic mix of roles and personalities who have different responsibilities, ideas and ways of working. It’s crucial for the PVS lead to be sensitive and aware of these idiosyncrasies and manage them accordingly to foster harmony and togetherness.

Multi-lingual: All disciplines use their own terminology, and tool, that is specific to their role. PVS leads must learn these terms and phrases and know-how to translate them to promote cross-team understanding, as well as provide guidance and leadership.

Cares how the sausage is made: Business leadership and customers do not care about how the sausage is made. The PVS lead ensures it always tastes as good as possible — and that there’s a process for continuous improvement so that the sausage quality is always at a high standard (and delivered faster).

Vision: A PVS lead develops and evolves the vision for the product. So while this role requires execution abilities, it also requires someone with the ability to “think big” and set a strategic vision.

Softening the Transition

You can take steps to mitigate disruption by concentrating on the people involved. 'Loss maps' factor in what teams fear they will lose through any cultural or structural changes:

We then took steps to ensure that roles and responsibilities were clearly defined and communicated. We set out what both team's career paths look like, and ensured that every discipline was recognized, supported and empowered.

Key Challenges and Benefits of a Product-Centric Journey

Like any transformation, the project to product transition is a never-ending process of experimentation, discovery and continual learning. You must find a balance between imposing change and driving change and accept results are not instantaneous. 

The benefits far outweigh the challenges. You’ll find that more customer-focused equals happier customers and happier employees. That less us vs. them results in more “we,” thus promoting understanding, shared responsibility and accountability.

You’ll discover that investment decisions are easier and faster. Finally, you’ll see that consistent reporting on how product value streams are reporting ensures you’re always delivering value to the customer.