Building Outstanding Product Organizations

Unless they are slowly fading away, enterprise software companies are living systems that continuously evolve. This means that not only are your companies trying to bring better solutions to the market, but you are always thinking about how to be more effective at doing this work.

This article takes a look at four key principles that should guide your organizations into becoming outstanding at building solutions highly valued by their markets.

What’s the Big Problem?

Everyday customer behaviors, technology enablers, and market context changes. Whether you are an early-stage startup bringing your first product to market or the clear leader in a mature market, it is important to always get better at how you operate in conditions of VUCA.

Companies must continuously work at developing an organization that can repeatedly create innovation in the face of challenges to drive your business of tomorrow. While better organizations survive, the best take these opportunities to out-execute competition to grow faster through sustained incremental innovations and periodic market transformations.

A company could put a top man at every position and be swallowed by a competitor with people only half as good, but who are working together.

What are the Symptoms?

It may be difficult to understand that your organization is not designed effectively to tackle the reality of changing market dynamics effectively. However, there are some symptoms that can be the canary in the coal mine, including:

• Sales driving new product commitments because you don’t innovate enough

• Competing directly on price and/or a feature matrix

• Delivering new products that fail to sell as projected

• Delivering new features that are not used or used less than anticipated

• Frequently late on roadmap planning commitments

• Higher customer churn than market averages

• Insufficient trust across functional areas of the organization

• Higher employee turnover, especially of top performers, than local averages

I could go on but will stop there. Most enterprise software organizations feel some of these pains at different points of their maturity. If and how the organization seeks to treat these symptoms is key to addressing the underlying disease. As a best practice anti-pattern, any changes that involve demanding more detailed planning or blaming specific individuals within the organization are the surest path to exacerbating these challenges in the long-run. More often than not, it is the system that is the problem.

4 Principles for Effective Product Organizations

Identifying challenges and opportunities for continuous improvement is the easy part. The harder part of enhancing your organization so that it can meet those challenges. Based on best practices of organizational design today, I provide 4 principles that you should consider when evolving your organization to the next level of effectiveness.

1. Customer & Outcome Focus

2. Autonomous Product Teams

3. Data-Driven Decision Making

4. Continuous Learning Mindset

Customer & Outcome Focus

Unless you are operating in a very well defined space, with little volatility, and have deep subject matter expertise, it is now commonly understood that the best products come out of deeply understanding your Customers.

Once Customers are understood thoroughly you can then think through the behavior changes, aka Outcomes, you want to achieve that align with your business objectives.

Activities and practices that demonstrate Customer & Outcome Focus include:

• Personas – Users, buyers, influencers and other stakeholders can be defined with fictional people that reflect typical individuals based on their needs, behaviors, experience, and goals. This helps designers see the world through the eyes of actual users.

• Jobs to be Done – Focus on the jobs that people are trying to accomplish, then figure out how to help them better accomplish those jobs.

• Customer Journey Mapping – Define the major activities and tasks personas undertake to achieve some objective through research. Once understood, then brainstorm “how might we” improve the various activities to achieve the outcome more efficiently or effectively.

• Outcome-based Roadmaps – Rather than defining roadmaps based on features you think will be needed in 6-18 months from now, focus roadmaps on the meaningful outcomes you wish to achieve. Subsequent discovery practices by the Product Team will uncover the solutions that best drive those outcomes.

Autonomous Product Teams

We know that the best chance to repeatedly arrive at the best solutions is to leverage cross-functional teams. For a typical product, this means minimally having a Product Manager (business representative), Designer (full-stack UX, UI, IA Designer), and Engineering Lead. Some products may require different functional experts like Subject Matter Experts (for deeply complex fields like pharma or legal), Data Science, and Test Automation also engaged on these teams.

For enterprise B2B software, this is often a challenge as organizations grow, teams multiply, and complexity increases. Still, there are organizational design best practices that have emerged to consider.

These include:

• Autonomous – The majority of work to discover problems and solutions should be handled by a team on its own.

• Full Scope of Responsibility – Teams should be responsible for everything from enhanced capabilities, to reducing technical debt, and fixing defects within their scope of responsibility. This develops deep ownership and expertise by the team.

• Long-standing teams – As organizational needs change and evolve over time, it is best to keep a Product Team together. Teams that work together consistently improve their effectiveness over time, even when moved to new products.

• Minimize Dependencies – While usually impossible to eliminate, it is critical to minimize the number of dependencies between teams. Every dependency creates a constraint not directly in the team’s control reducing their autonomy at problem-solving and, therefore, reducing their effectiveness. Dependencies that must exist have to be managed closely.

• Objective Driven Planning – A very popular tool for driving organizational strategy is OKRs (Objective and Key Results). Whether using OKRs or another objective-driven planning approach, the key is to set periodic objectives for the Product Team and they need to figure out how to best achieve those objectives. These team objectives should not be used for individual performance reviews but instead should be aggressive targets teams strive for but rarely hit 100%.

While adopting objective-driven planning is a mindset change within an organization, it can be readily achieved with sufficient senior-level support. The real art in successfully carrying out organizational design practices is determining how to split products and product areas into separate teams.

Understanding, the need to minimize dependencies and provide full responsibilities in a product area are key. Coupling this with proper team sizing (5-10 people) and recognizing Conway’s Law is a head start to creating optimal product teams.

Data-Driven Decision Making

In the past, the waterfall development methodology demanded extensive up-front market research to define opportunities that reflected unmet and underserved customer needs. Then after applying some R&D insights on available technology, a detailed development plan with features and release milestones was laid out over a multi-year planning horizon.

If any evidence arrived during the development, pre-launch, it was rarely taken into account to change those plans as the budget has already been approved based on very specific deliverables. Even when Alpha and Beta testing were part of such plans, the feedback was mostly used to incrementally improve the quality of what was always going to be delivered.

Today, lean and agile practices change everything. Lean tells us that shipping anything that is not eventually used is waste that the business should try to prevent or minimize. Agile says that we must be able to adapt our plans as new facts arrive.

Together with continuously evolving tools and techniques for capturing data before and during development, then continuing after go-live, Product Teams have a very powerful means to improve decision-making through data rather than educated guesses and opinions alone.

Practices, tools, and techniques for leveraging data in decision-making include:

• Customer Development, Improvement Kata, or Lean Startup’s Build-Measure-Learn loop to hypothesize on ways to affect the desired outcomes, then iterate to collect data, learn and adjust efficiently.

• Data Instrumentation – While this is easiest to do with cloud-based software, collecting usage data can be done with on-premise software, embedded software, mobile, and IoT devices. Such data can inform decisions on product utilization, patterns of use that can be optimized, and give early indicators of product deficiencies.

• Feature Flagging – The ability to deliver product capabilities and test them incrementally before rolling out based on evidence of improved outcomes.

• A/B Testing – Most suitable for cloud services but can creatively be leveraging in product discovery and to support other tasks, Product Teams compare two or more design options with usage data to determine which is the best choice before full rollout.

• Online Target Market Testing – Research tools now enable large scale tests of hypotheses on everything from user needs, behaviors, and pricing strategy, to gathering feedback on prototypes.

• ProductOps – a dedicated function or role within product organizations to help identify opportunities to leverage data in decision making and efficiently scale its usage across the organization.

Organizations that excel at data-driven decision making look for ways to reduce their risks by collecting and analyzing data, wherever practical.

Do we have data to support this decision? If not, is there any way we can get the necessary data?

Continuous Learning Mindset

The entire organization has a responsibility to continuously learn. There is the learning intrinsic to each team member’s functional area of expertise, but there is also a need for all to learn and share about the business, market, technology, and customers.

This is where the cross-functional team previously described adds a lot of value in cross-pollinating ideas, knowledge, and lessons learned from different domains. Teams are able to efficiently pattern match from other areas, apply lessons learned from analyzing competitors and other market participants, and come up with the most promising hypotheses to test.

What do organizations do to encourage continuous learning?

• Market Intelligence Access – Provide access to tools and external data that can accelerate team learning. The best services can cost significant money but the return on investment can be significant.

• Hackathons – Periodic design sprint events allowing ad-hoc teams to get creative at identifying and solving internal or market challenges.

• Technology Research – Larger, mature organizations specifically fund ongoing research that is directed at Horizon 3 planning for disruptive innovations. This research is not measured by direct or immediate market benefits but through its success at uncovering opportunities to lead through dramatic market transformation cycles.

• Professional Education – Provide investment for ongoing professional development within and across disciplines.

• Product Team Field Research – Enables all members of cross-functional product teams to visit customers, prospects, and partners to get direct exposure to critical market participants.