Reflection – Learning Launch

Challenge & Selection

I am a lead Design Engineer in a startup which focusses on automating mundane processes of item  storage, retrieval, and dispatch, in large warehouses. Since we provide automation solutions to  businesses, there is a lack of direct interaction of engineers with the eventual end customers. The  company started off with a small team who built a compelling solution for businesses, the adoption was  rapid and sales were good. Later, it became apparent that the designs had several hidden limitations  which the team did not anticipate early on, such as, scalability of production, reliability, maintenance,  assembly, cost etc. While initiating the development of a new product platform, we wanted to avoid a  repeat of the mistakes made earlier. Learning launch tool was the perfect tool to get things started and  to refine our product development process. Using learning launch meant that we could iterate/ refine  various steps of our product development process quickly. As a pilot, we tested a new approach in one of  the product teams. We started by identifying our key stakeholders who could present clearer  understanding of internal and external customer demands, identify problems, eliminate decision  blindness, encourage different lines of thought and shorten development times by designing and  validating quick prototypes.

Application

We started out by scoping the review team. This team would be responsible for final approval of design  decisions and would comprise of heads from all the major departments in the organization, thus ensuring  that every viewpoint gets taken care of. Insights from the marketing and sales team were hugely beneficial  in understanding the pain points and expectations of the customers, this information was passed on to  the technical teams. We then formed cross-functional engineering teams (CFTs) within the organization  to work on specific modules of the product, modularizing the design was a key decision taken early on to  eliminate a cascading effect of failures identified later in the product’s life cycle. Thus, ensuring that  correct engineering decisions get made at the individual team levels as well.

At the beginning of the product development, the CFTs would start by ideating on multiple design  concepts which solve the problem. The teams would then shortlist 3-5 designs based on evaluation by the  engineering and production teams. The engineers will then start developing mature versions of the design  and prototype them (POCs - Proof of Concepts). The POCs would then be tested for technical conformity,  in some cases scaled prototypes would also be built to reduce cost and time. After eliminating the  concepts which had fundamental drawbacks, the remaining designs will be presented to members of the  review team for approval. The team would include the CTO, heads of sales & marketing, engineering,  production, validation and customer support etc. This meeting would surface a lot of the issues which  went unnoticed by the engineers, it would prove to be a learning platform for the team to modify and  enhance the designs. The outcome of this meeting would be to improve current designs according to  feedback received from various stakeholders, eliminate non-feasible design options, or pick the most  appropriate design which meets the overall goals for further development.

Insight & Approach

This activity was done to evaluate design outcomes of all CFTs, and it was helpful in eventual selection of  the best designs which move forward to production. The activity also helped in aligning the thought  process of all individuals, making everyone understand different viewpoints, challenges and limitations.  Thus, by the end of the exercise everyone would agree on the chosen design due to its overall merit and  ability in solving a complex engineering problem spanning multiple disciplines. The side-effect of this  approach was also improved motivation among my team members, getting an insight into ideologies of  other CFTs was an eye opener for many, it was an opportunity for growth.

The CFT approach for product development was adopted throughout the organization following the  successful execution of an entirely new product platform. With lesser time, better product quality, better  reliability, and improved production/serviceability compared to previous approach of working in silos and  not encouraging a wide debate in the decision-making process (relying purely on engineering excellence).  It was a lesson in entrepreneurship and team building for all members involved and showed the  importance of adopting different methodologies of work depending on the situation. The actual  implementation was a bit more challenging to finalize and execute but I have summarized the gist of the  approach.

Personally, this approach was truly educational for a left-brain thinker like me. Sometimes the best  engineering solutions are not the best for solving the problem. Objective metrics such as cost/ product  performance/ quality/ reliability are not the only metrics driving product decisions, it is a mixture of  several elements with the right amount of compromise which builds a good product like ours. Group  thinking and learning through experimentation really helped in proving this point.

