Weekend Reading – The Benefits of Product-Oriented IT (Redux)

“Good companies manage Engineering. Great companies manage Product.” – Thomas Schranz, Co-Founder & CEO at Blossom

Dear all,

Last week I wrote about fighting application bloat and scope creep in (especially) IT applications. In doing so, I suggested it to be beneficial to switch to a product-oriented IT model.

While it is not always easy and straightforward to come to meaningful product definitions for „IT products,“ as we learned again this week, the benefits of the concept are still overwhelming.

Let me summarize again in a few paragraphs why I believe a product-oriented IT model offers several benefits over a typical IT project organization.

• Value generation focus: Product-oriented organizations prioritize desired user- and business outcomes. By aligning teams with specific products or services, they can gain a deep understanding of their target business, audience, the JTBD, and desired business outcomes, resulting in better user and customer satisfaction and a positive business impact as a consequence.

• Ownership and Accountability: In a product-oriented model, teams have end-to-end ownership of their products. This sense of ownership fosters a greater sense of responsibility, accountability, and often motivation among team members. They are invested in the success of „their“ product and strive for continuous improvement.

• Cross-Functional Collaboration: Product-oriented teams bring together individuals from different functional areas, such as business, development, testing, and, ideally, design. This cross-functional collaboration fosters knowledge sharing and typically leads to better overall product outcomes and more innovations.

• Continuous Improvement: In a product-oriented model, teams are organized around specific products or services. This allows for a continuous improvement cycle, where teams can focus on enhancing and evolving the product over time. This iterative approach enables faster feedback, shortened release cycles, and better adaptability to changing business and user needs.

• Long-Term Stability: Unlike project-based organizations that disband after project completion, product-oriented teams are more stable and can build long-term relationships with their products and the business it serves. This stability fosters expertise in the specific product domain, builds institutional memory and related skill development.

• Reduced Redundancy: In a typical project-based organization, similar functionality may be created separately for different projects, resulting in redundancy and inefficiency. In a product-oriented model, teams share a roadmap, allowing for better coordination, component reuse, and reduced duplication of efforts.

Beyond organizing in product teams some challenges must be overcome to be able to reap these benefits.

The most critical is a „feature factory“ mindset, where teams are asked to implement predetermined solutions or features defined by a management layer typically somewhat removed from the actual business and front-line staff.

Implementing product teams and telling them in detail what to do will not unlock their full potential. For product teams to thrive and generate maximum value, they need to operate in an environment where

• Product vision, JTBD, and business goals are shared and agreed between the product team and (business-) Management
• The team‘s deliverables are framed as desired business impacts or problems to be solved rather than specific solutions to be implemented
• The team is given the autonomy to test, learn, and apply optimal solutions within a structure of business objectives and constraints outlined by the company or department.

Regularly reviewing and discussing business goals, product vision, and constraints is crucial to staying in sync with the business. This can be facilitated, for example, through Quarterly Business Reviews or an OKR framework.

IT product teams may vary in makeup based on an organization’s history, customers, users, resources, and business goals. Still, we typically encounter three categories:

• Market Facing Products Teams. Teams that are building or contributing to products and services for external customers. These teams and their products are impacted by the same forces that apply to any app or other digital product.
• Internal Products Teams. Teams that create products or services that are consumed by internal users (e.g. buyers, financial analysts, …). These products are often governed predominantly by business objectives and constraints and operate in a somewhat „protected“ domain.
• Enabler Teams. Teams that are building technological solutions and platforms to help the above types of teams solve an expanding set of similar problems. Often simplifying a complex technology for their use by means of creating a set of common APIs or similar.

With increasing digitalization, many IT organizations will ultimately harbor all three types of teams.

Transitioning to a product organization is challenging for most IT organizations (Don’t worry, we’re here to help!). This week’s reads may spark some thoughts:

Team topology: 6 “first principles” for product leaders

Afonso Franco applies the Team Topologies principles to product teams

Click to view!

Summer is back again (at least here in Bavaria). I am off to the lake.

Have a great weekend,
Godehard