The truth about Products
By: Anuj Gautam
Tags: Agile, Digital, Information Technology, Software, Technology

Courtesy: Unsplash

The success of born digital organizations is lately driving many choices in the traditional organizations who have years of legacy to shed off. Most of these born digital organizations do not own or drive an actual operation, they are built for speed and strive on technology as a core capability to scale out.

And on the other side we have traditional organizations who have built an IT support function over years tightly coupled with its Business and Operations function. Prime focus all these years was for building endurance and now they are being pushed to redesign,compete and disrupt in the digital era.

In the centre of this digital universe lies the concept of a “Product” which is expected to drive the vision and mission for digital proliferation in an organization internally and externally. The products are expected to have a purpose and a behaviour which can be demonstrated to an audience and benchmarked for improvement. Products are supposed to work in the digital realm with lots of autonomy and are the fundamental block for defining the new organisation culture.

The whole idea of Products starts to fall in place if one is starting from scratch. Imagine if you as a new start up or an ideapreneurs who have identified a need for carpooling solutions for weekend travel out from the city. You can investigate, identify the value proposition, ideate, and refine the idea and can start building a prototype. Throughout the process you will have flexibility to make choices like who are the people you want to involve, what kind of technology you would like to use or what will be your go to market strategy. And if your idea clicks, you can keep on scaling up until you may end up being the next Uber or Netflix. The key take away in this approach is that you were able to start fresh and everybody working on the products and concepts knew from day one the script to be executed.

In a parallel world, we have an organization which had worked traditionally all this year and now suddenly we want to build the idea of Products centric appoach to scale digitaly. Fundamentally in these organization the IT was an enabling function all along and core business and operations are way off from the new digital trends and possibilities. In the initial phase, it generally ends up into lots of permutation and combinations of organisation & process design, technology shake ups until we have a basic Products view emerging. The emerging view of the Products may be very subjective across organizations and will be dependent upon type of business, geo reach, size of the organization and existing legacy set up.

The whole process of this movement into a Product centric organisation may range from few months to years. The benefits of such a move may not become visible in short term and may often result in panic and disillusionment. Very few organisations will be lucky enough to come up with new digital themes and ideas disrupting the existing model in its first iteration.

Currently there is no excuse for not spending on digital transformation, but it is always good to make a note of things to watch out and proactively try to quash their impact. Below points are subjective and may appear in different form and state but almost all of them may hold good for any large-scale organization moving into a product centric set up.

1) Relationship with Business and Digital Organization

In traditional organizations the Business and Operations function will continue as usual and are unlikely to change ways of working overnight.The transition of vision from a Business Owner or Process Owner to a Product Owner is a critical ask. If they are talking two different languages, the product is bound to fall short on acceptance. The transition will be easy in capability areas where digital touch points exist with end customer or co-workers and business & operations are savvy enough in drilling down from user needs to product backlogs

2) Hybrid Organization design

The biggest challenge for a traditional organization is to define the operating model. The existing functionality at some places can be imported as it is to the new and at other places the new principles of Product design may not be applicable and solution-based model may be easy to comprehend. A uniformity on a Product centric organization may sound cool but should not be a fixation. It may make sense to have a hybrid approach until a strong digital foundation is in place.

3) Too Many Roles and Split of Responsibilities

It is advisable to restrict the number of roles defined in the new model. The newly defined roles should be able to perform a broad range of tasks and not stick to textbook definitions. More the roles more is the level of delegation, often resulting in challenges to track the business value being delivered through the initiatives. If you see this happening, it may make sense to investigate the Product team and Organization design.

4) Domain Driven Design and Business Capability Overview

The products should have strong relationship with the Enterprise Business Capability Model to have an aggregated view. It may also make sense the Products are viewed through the lens of a Domain driven design so that we have clarity on bounded context, domain boundaries and dependencies. Domain understanding and context is taken for granted in several scenarios, resulting in complex products being designed, which in long run are difficult to maintain and develop.

5) The principle to measure the transformation

The fundamental remains the same what is the purpose of the product and how can we measure the impact? Will the new product help in improving shopping cart abandonment or increase conversion rate? Is it a product or group of products — which is going to compliments the Organisation Objectives? This needs to be articulated, along with the dependencies between the products so that each product is designed with a clear mandate.

6) Products, Product Groups and Solutions

Products are easy to conceptualize and deliver when there is an end consumer involved. You can interact with the end consumer and work along with them towards an MVP.

The products which are more domain centric or are supported by an ERP package or a custom application are difficult to conceive and deliver. The dependency factor between various functions is very high. You may end up with quite a few Product modules and the best way to visualize them is at an aggregated family level based upon the bounded context for the domain and the targeted business value.

And than we have systems which may not qualify to be transitioned into Products, for e.g. System of records. These should be handled as solutions and if required discussed for transformation in their given constrains.

7) Two Paced Architecture

In initial phase it may be advisable to build a two-pace architecture with faster rate of change on Customer / Co-workers facing capabilities areas and may make sense to have a conservative rate of change on core functions. Defining Products may be a central theme and mandate but if there is no architecture support, the Product should be stopped until the fundamentals are in place.

8) Technology and Tool choices at Hand

The Product team enjoys autonomy to work to various degree in each organization. Is it an enterprise wide decision or local product team decision for choosing the technology is a debatable point in most organisation. For the phase One of the transformation, it may be good to use mainstream technologies adopted enterprise wide. And as the organisation matures the Products teams can start making individual choices to nurture and maintain specific technologies and tools. If not done correctly you may have too many similar technologies in your catalogue and very low technology skill maturity in the organisation hampering productivity in the long run.

9) Reskilling versus new hiring for digital

All digital skill set may not reside in the organization and hiring all skills may not be viable option as it may have an adverse effect on the speed of transformation. A balanced approach is required to be defined upfront by clearly defined quota for reskilling, new hiring, and outsourcing.

10) Avoid too many Products

With the retro fit model, the biggest challenge an organization may face is too many products defined, developed, and managed. All products should start with a well-defined business value and a roadmap. If the product features cannot be exposed directly to the end consumer, it may need to be reviewed for its definition.

11) An Audit Trail for Products

It may be a good idea to have independent review of Products from time to time to see if they fit the organization defined definition for product or have fallen outside the grid. You for sure will not be building Products for the sake of it and will try to keep your slate clean. Once you have false products recognized, developed, and maintained you have unwisely accepted future technical debt.

The list may go on, but I hope the above point are able to support the argument that a traditional organization should better try to have True Products in the portfolio than error falsification recognized. A successful transition is a must have for a traditional organization with correct definition of Products as it attempts to cover years of digital journey in a very short time frame compared to a born digital organization. Success and failures need to be acknowledged and appreciated in the same vein and used to define the next actions. Once you are on the digital track, it is a one-way traffic with no stops and continuous recalibration on the way to remain relevant. The above point of view is an impression and can be deliberated to different extend in any organization for its validity.