Optimizing the product toolchain like a Lego

Optimizing a product toolchain and workflow is fascinating and every product owner has been there. Let’s be clear, every product manager out there runs through the challenge of optimizing costs on development, maintenance, production, marketing, etc. If the optimization problem was so simple, then it won’t be least as interesting. One of the key areas while building a product, that turnout often ambiguous, are the decisions on choice of toolchains and how they are implemented into a workflow. Having worked across several different pre-development teams I can assure you the challenges in building up a process and optimizing it.

Photo by Markus Spiske on Unsplash

What could help managers is a set of guidelines to refer to, that helps milk out the best from their toolchains and builds an understanding of the parameters that influence decision making when it comes to gathering the tools for the toolchain. You can read more about building your custom tools versus buying easily implementable tools decisions for your product development here, which would eventually help answer the next questions.

Why do we need to optimize our toolchain in the first place?

I use cases from the automotive world as a reference in this article, majorly also because this has to do with firsthand experience. When we have the wrong tools in our processes, its utter chaos!

To look out for at all costs:

1. Useless tools
2. The absence of tools
3. The presence of tools that make the process not efficient and longer
4. Version mis-management
5. Wrong licensing deal not aligned to the easy of the users

Let state an example of why. In the pilot projects for selling utility of software products that I have worked in, we generally have a high priority on quality and timeline, for the product showcase. And in these projects having development tools that are still in nascent stages of development can be a huge nightmare and not so good for the end product! High attention needs to be paid while deciding to use the right tools and at the right stages of the product life cycle. In the cited case, the idea of having in place custom-developed tools is good in the long run but critical when having your first releases and pilot project.

One more example that comes to mind, about missing tools in the toolchain. One of the companies I worked for had a working development chain in place and that point a decision was taken to freeze the tools in the process for bureaucratic reasons. So even though tools such as cameo that helped in data fitting, would have helped the development projects, and the licenses were also available, it was just not used because we missed out on having the flexibility to review the tools constantly. Having additional review tools put in place, originally to ensure the quality, were so inefficient especially in cases where the developer and the reviewer were sitting side by side waiting for approval from the bosses. Adopting a global large toolchain process into a small team is an issue. The examples are innumerable when it comes to having the wrong toolchain.

Bad toolchain and processes

A good toolchain on the other hand

1. Aids innovation: A company where I worked for had put together a very efficient process while building their product. They foresaw this as a utility for auto manufacturers and today they sell their methodology as much as their product.
2. Helps create stronger communication: A good toolchain always influences communication positively and helps make it more efficient. As an example introducing a team-Wiki with confluence helped discuss lessons learned from different developers in the team meetings and engaged more conversation among the group. This could have also easily been done in a shared folder structure with PowerPoint presentations but the importance is to have the structure in place.
3. Reduces redundancy: A toolchain helps the project get faster reducing the redundancies. It aids the development of libraries and platforms so the main focus is on the innovation of functions.

Maximizing Toolchain utility

Parameters to look for in understanding if your toolchain is right?

We have established that we need a constant look at our tools and processes and why this is very essential. The next question when it comes to decision making is how to look at it and what factors to account in when we do. In a basic development cycle, we use different tools for requirements management, implementation of functionalities, testing, project management, Issue tracking, knowledge sharing, documentation, and the list goes on. With several different tools in place, which tools fit the goals we have in mind and the style of the team and which can we eliminate? which tool can be used to do multiple tasks? how can we get more from re-structuring them? Is a pure investment in stronger and better tools a good strategy?

Let us take a look. There are some important factors when it comes to understanding if the toolchain you have is sufficient for the goal:

1. Project Size Team Size awareness: There is no big return in having the best tools with high costs for small budgeted projects and very small teams. Often times smaller teams can function well on lesser tools.
2. Scalability and time: The question to upgrade to more compact tools comes with a plan for scalability and the time set up to achieve this.
3. The communication model within the team: If a tool in a toolchain is not influencing the team to communicate well with each other the tool can be thrown out.
4. Easy Transferability: the idea of scalability must ensure decision-makers to think about choosing tools that are open-ended and can be easily transferred into new systems.
5. Team Style and licensing: This is very important, if the team prefers to working remotely then the idea of shared floating license on a single tool is more feasible if their load is high and the number of team members is low perhaps a single license on a simulation PC could be better
6. Costs of tool maintenance: For a sustainable business the product is all about the revenue it generates, we do not want to spend a major part of the development budget in tool maintenance and fixes when it is not even needed.
7. Tool Utility tracking: index tool utility on a regular basis and getting the idea of how much each tool is used and why. Matching the capability of the tool to fill in the gaps for our ideal process could help make better decisions.

How to get more out of the tools?

1. Review workflow: Periodic, suggest a bi-weekly process review

2. Quantitative assessment: Indexing the utility based on time used per calendar week, no of people used, no of functions it covers, and importance of the tool and normalizing it to a 100-point scale would help comparability. If you have further interest in how to do this, feel engaged to get in touch.

3. Lego out and Re-Lego: “Lego” in Latin means to gather, but it is also important to remove the Lego pieces out to make your product beautiful and well defined.

Closing notes to keep in mind

1. Review your toolchain regularly and get people to participate
2. Quantify the tools with an indexing system that addresses the intended use, normalize it and compare to different sets ofr helping decision making
3. Get constant feedback from the team on how good the process is and ideas on how else the tools could fit better into the workflow
4. Have a clear scalability plan and awareness on the return of investment on toolchain dollar spent
5. Invest in benchmarking toolchains and having a defined list of the pros and cons on why you choose specific tools so it makes reviews easier
6. Be aware of the cost and licensing model, and maintenance
7. Don’t be hesitant to re-lego your toolchain!