Creating Value with Product Engineering

Being a professional Engineer, coming from a family background of multiple generations of Engineers (my Grandfather, Great-Grandfather, and Great-Great grandfather all graduated from Politecnico di Milano), I have always been fascinated with engineering techniques and skills that led to complex solutions and achievements standing the proof of time, from the remains of ancient Romand building, aqueducts, and bridges up to modern Telecommunication networks.

Having focused my technical career on software and IT, I soon started wondering how to apply engineering techniques in this field. My initial experiences showed a mix of situations and methods, with some components developed in a quick and dirty way through hurried projects while other components developed with more relaxed timelines showed signs of overengineering and additional complexity.

The more complex my engagements become (such as industry-specific business platforms) the greater the need to find a way to balance effectively these two mindsets.

Product vs Project Mindset Dichotomy

When developing an industry-focused business platform the choice between product and project mindset strongly impacts the success of the platform and the business that relies on it.

Project Mindset: focus on delivering a specific outcome within a defined timeline and budget. Project teams are often formed to deliver a specific project, and once the project is completed, the team is disbanded.

Product Mindset: focus on creating a sustainable, long-term solution that meets customers' needs. Product teams prioritize building a robust, scalable platform that can adapt to changing market conditions and customer preferences.

For a business platform, a project mindset provides time and cost control but can lean too much on short-term goals. Conversely, a product mindset requires a long-term commitment to investing in the platform, continuously improving it, and adapting it to meet the changing needs of the business and its customers.

How can we address these challenges in adopting a product mindset?  

Agile Methods

Agile can be a good starting point for managing a business platform with a product-centric mindset because it emphasizes iterative development, customer feedback, and collaboration between cross-functional teams. Agile methodologies, such as Scrum and Kanban, provide a framework for teams to quickly respond to changing customer needs and market conditions while ensuring that the product meets customer requirements and delivers value.

By breaking down work into smaller, manageable chunks, and regularly delivering functional software, teams can quickly validate assumptions and adapt to changing requirements. Agile fits with a product mindset, with terms and definitions such as "Product Backlog" and "Minimum Viable Product (MVP)", but at the same time includes principles that can mitigate overengineering and keep complexity down (e.g. YAGNI in eXtreme Programming).

But in the end, even if Agile encourages collaboration between teams, it's not always adopted in an end-to-end fashion, especially in organizations that are not purely digital and Software-based.

How can we go over and further systematize the engineering approach?

Product Engineering for Industry Domains

Product engineering is creating and seeing a product through its entire life cycle from conception to end-of-life. Product engineers are responsible for designing, developing, testing, and maintaining products. This is true for both physical and digital software products, going beyond an Agile Software development approach.

Product engineering involves overseeing many aspects of the product, including its quality, cost, performance, usability, reliability, lifespan, and serviceability. Without product engineering, a product would remain an idea, so it plays a crucial role in developing a product.

The industry of product engineering is on the rise, and also IBM is getting involved in this field, having acquired Dialexa company.

Product Engineering can combine Agile, DevOps, and Lean principles with Industry and Domain-specific skills to create a holistic approach to end-to-end product development in customer organizations not limited to IT.

Product Engineering requires a multidisciplinary effort to be adopted and has to be actively managed to be effective.  

How can we find out when and where this approach should be used?

Component Business Modelling (CBM)to narrow the focus

To evaluate where to narrow the focus for adoption, it is key to start with a strategic analysis based on the specific Industry and Business context. At IBM we have a framework to approach this kind of decision, called the Component Business Model (CBM), that can be used to map the company's Business Components.

An analysis can be performed, comparing the specific company model with a reference for the industry sector, and with the support of the model, strategic decisions to focus on some Business Components can be made (E.g., strategic Business Components are marked in Blue in the picture below).  

CBM can be used to select focus areas for Product Engineering in a company belonging to a specific industry in the following ways:

1. Identify industry-specific pain points: using customer feedback, industry trends, and market research to identify the most pressing pain points and opportunities for improvement.

2. Identify areas for differentiation: analyzing competitor data and industry trends to identify areas where the company can differentiate itself from competitors. This can help Product Engineering focus on creating unique and innovative solutions that set the company apart from others in the industry.

3. Improve strengths: finding areas where processes and solutions are already strong and can be further optimized.

This can help Product Engineering streamline their workflows and free up resources to focus on high-impact areas. At the same time, on less strategic and lower priority ones,  more standard packaged solutions or commercially available services can deployed with a Project-minded approach.

Conclusion

Using a combination of these elements as a reference frame to set up an end-to-end Engineering process can lead to creating effective and long-lasting solutions, in appropriate scenarios, and avoid over-engineering in less strategic, lower-value situations.  

With this approach, I have been able to lead the design and implementation of a strategic Commercial Platform for a Railways industry client. The key enabling decision together with the client Business Architecture team was to start everything with a CBM approach. From that, using a Domain-Driven approach to design the system, and an iterative delivery process using DevOps, the business platform was implemented, became a strategic asset for the Client, and was successfully evolved and re-used on several business initiatives.