Are you “only” involved in purely digital / IT products, then you might want to skip this post … unless you want to appreciate the complexity being faced by people working with multidisciplinary products.
The modern high-tech product company needs at the same time to optimize for
-
- Fast-paced product innovation
- Production with a consistent quality
At first glance it can seem like an attempt to mix oil and water, but never the less this is mandatory for success. If you want your customers to love your products, you need to supply products that (inspired by Marty Cagen)
-
- are valuable for the customer
- are useable for the customer
- meets the customers quality expectation
(1) and (2) basically have to do with the Discovery of the right product. (3) is in essence about predictive (physical) production. As mentioner in an earlier post, Tesla is an (extreme) example of this.
This post will discuss the full Product Lifecycle from early innovation to (physical) production, and the continuous product improvement feedback-loops.
In a hurry? Jump directly to the wrap-up.
An overview seen from the height of satellites
This is the top-level view of a Products Lifecycle. It gets
- invented
- produced with continuous improvements
- phased-out
From this height of satellites we do not see the details on how
- the product is born
- the product is matured for production
- the on-going product improvement loop works
The need to deliver what the customers need, with the right quality and in a lean way is far from new. The various flavors of e.g., Six Sigma, dating back to the last millennium, exemplifies that.
Add to that the suite of other ISO quality standards, project models and of course the Agile spin-offs for non-software domains as e.g., in this book (which by the way includes a description of how Saab Aerospace applies Scrum in the development of the Saab JAS 39 Griben fighter jet making it highly competitive to Lockheed Martin’s F35 fighter).
Feeling a bit overwhelmed?
Take a deep breath!
Do not let all these frameworks / models / standards drag you around. Just like you do not want to be enslaved by “the right way to do Scrum” or “the right way to do PRINCE2”, you do not want to build a bureaucracy with process prescriptions not working for you.
There is only one right way, and it is the way that works for you!
What I highly recommend is to invest (a lot of) time understanding all the various standards, frameworks, models, tools etc. thus acquiring the insight needed for you to take enlightened decisions on what elements to use and what not to, given your unique context.
Elon Musk is very clear about (too many prescriptive) processes:
Elon Musk
In the case of Tesla, being a digital-native company, as much as possible is automated with a heavy IT-setup and state-of-the-art robotics. So yes – Tesla has a lot of processes, but processes to be followed by machines. The intellectual and innovative part is not dragged-down by strict process prescriptions or multilayered project governance. I guess (not being a Tesla employee) that Tesla has a versatile pick & use toolbox of good practices and tools. As mentioned earlier, Tesla uses Communities of Practice (CoP) to share and develop knowledge across teams.
OK - so what do we then do?
Assuming that you have done your homework, having a deep understanding of your own business and having equipped yourself with a solid understanding of all the relevant methods, frameworks, standards, tools etc., you can start the hard work.
You might want to use your Time Machine travelling the Product Lifecycle all the way from the initial inception of a product-idea over innovation to production, continuous improvement and finally to the phasing-out of your product. During your journey keep asking a few simple but important questions for each time-jump.
Before looking at the questions, let’s define a few assumptions and recommendations:
- Assumption: Throughout the Product Lifecycle you want to find the right balance between formal structure and flexibility. This balance will naturally shift depending on, where you are in the Product Lifecycle.
- Assumption: You consider the intellectual capacity as the most valuable asset in your company thus being very aware of, how you use it:
- Where IT-systems and/or robots can do the job, don’t waste intellectual capacity
- To the extend you define formal and mandatory processes, you’re making sure that they create business value
- You want to make it as easy as possible for your employees to do the right things the right way
- Recommendation: Do not answer the questions with “we need to do that because model / framework / standard xyz dictates us to do so“. You need to see these models / frameworks / standards etc. as optional means to meet your objectives; not objectives themselves (with a few regulatory exceptions).
- Assumption: You consider the intellectual capacity as the most valuable asset in your company thus being very aware of, how you use it:
Here are the recommended questions:
- What minimum viable structures and processes do we need to facilitate alignment in the organization?
- What can we do to get the most business value from our combined intellectual capacity?
- What can we do consistently to deliver the quality expected by our customers?
Answering these questions you can, if relevant, consider elements from the range of models / frameworks /standards / tools etc.
That is just common sense!
You might be thinking “this is just common sense – nothing new here!“. The reality is that most companies have a natural tendency to build bureaucracy, “talking to itself”:
The typical spine-reaction to increased complexity in classically structured organizations is stricter Project governance, more control bodies, stricter and increasingly complex Project process prescriptions, more checklists, more reporting, more detailed planning – even for stuff that cannot be planned. Decisions are delayed, needing to travel up and down the hierarchies. The odd thing is that the biggest decisions are taken far away from where the biggest insight and information is. A bit sarcastically some describe this as “HIPPO” meaning the Highest Payed Persons Opinion.
Not convinced? Read e.g., the book Pseudo-work: How we ended up being busy doing nothing.
In other words: if you’re not tough on the recommended questions above, then the auto-pilot in your organization will bring you to another destination characterized by more or less untethered bureaucracy. This has and is happening to a lot of organizations. Guess why you see all the “Agile Coaches” popping-up wanting to free organizations from the burden of bureaucracy through “Agile Transformations”?
True, an external facilitator is often an effective way to get such a transformational process going – though it is not rocket science – just hard work (and it is!)
Example context
Before going for a quick ride in your Time Machine, let’s assume the context outlined earlier with a high-tech product company innovating and producing a range of multidisciplinary – a combination of high-precision mechanics, hardware (power), electronics, embedded software and application software – products.
The company has decided on a brand-new product range with intelligent capabilities making it predict and seamlessly adapt to a users needs. This product range is expected to have it all (though depending on the solutions discovered by the Product Teams):
- Electronics, sensors and IoT-connectivity
- Embedded software
- Hardware (power)
- High-precision mechanics
- Mobile application
- Cloud services leveraging the computational power for the Deep Learning AI
It is a B-t-B product intended to be integrated in other OEM’s product range like robotics.
The company has been through a big digitalization / Industry 4.0 transformation process in its quest for the holy grail: fast-paced product innovation. The company is now highly digitized enabling the Product Teams to have e.g., real-time updated BOM-cost estimates (and estimated lead-time) available. The company has also come a long way with its AME (Advanced Manufacturing Engineering) using robotics, industrial IoT, Machine Learning etc. All bits and pieces are traced through solid Configuration Management (including e.g., PLM – Product Lifecycle Management).
Each produced product instance has a fully detailed configuration following that instance to the grave. As described earlier with Tesla, the company is capable of changing components during serial production and maintain full traceability for its use in specific product instances.
Broadly speaking the company has two types of products, the ones that
- are very stable in production during the Product Lifecycle having no or very few changes / optimizations
- are expected to evolve radically with a lot of changes, needing a high degree of agility in the production
The production set-up for the first type resembles the traditional lean one-piece flow (for which Toyota is famous with its TPS). The company’s production set-up for the 2nd type resembles what Joe Justice calls Massively Parallel Concurrent Manufacturing [MPCM].
- Traditional lean one-piece flow (the Toyota production system is famous for it) makes change very expensive … encourages getting it perfect before deploying to production … resulting in long lead-time for changes … which again delays getting feedback from production to improve design … rendering the slowest possible deployment cycle. The traditional lean one-piece flow is completely inappropriate if you want speed of change!
- In contrast, Massively Parallel Concurrent Manufacturing [MPCM] is optimized for change. Here there is no one-piece production line at all
- In MPCM we’re using massively automated unit and integration tests (like with a build-server in a software environment)
Joe Justice
In his example we’ll assume that the new product-range is of the 2nd type – that is MPCM – with a need for a very high degree of agility in the production.
During the digitalization transformation process it became clear to the company, that it over the years had built too much of a bureaucracy in an attempt to control and set rules for everything. Now the company has shifted 180 degrees towards a Minimum Viable Bureaucracy.
In “the old days”, before starting to use stable cross-functional Product Teams, the company would follow its project management process, in its core being inspired by PRINCE2. Its approach to this new product-range would initially be to build a Business Case arguing the viability of a product development project.
Today, looking in the rearview mirror, the company has come to realize that such a Business Case included a lot of guess-work for the simple reason that the solution was not known at the time of writing the Business Case. The company has taken the consequence and changed the way it funds product development: today it uses a Venture Capital [VC] approach with metered funding.
Instead of the classic governance reporting compliance / deviations to the (doubtful Business Case), the Product Teams (being accountable for the Outcome) now act with the mindset as if being (an internal) start-up seeking VC.
In the “real external world” of start-ups you’ll be expected to convey a convincing set of arguments, for why the Venture Capitalists should (continue to) fund your endeavor. You have to be concrete and facts-based in your arguments e.g., referring to validated experiments and new insights. Try show a Business Case based on guesswork, and you’ll probably not get the requested funding.
At some later stage you’ll have gathered enough evidence and certainty to provide valid estimates on market potential and cost to expand production. Given the need for a major investment in production capabilities, it would be natural at this point in time to provide a Business Case (which a real Venture Capitalist would request).
Example jumps in the Time Machine
Given the example context above we’ll make a few time-jumps, each time asking the three questions
- What minimum viable structures and processes do we need to facilitate alignment in the organization?
- What can we do to get the most business value from our combined intellectual capacity?
- What can we do consistently to deliver the quality expected by our customers?
The VC-style funding model will not be mentioned as is applies everywhere.
Time-jump - Product Teams have been tasked with (hard) problems to solve
We’ve jumped to the point in time where a network of Product Teams has been defined and each Product Team has been tasked with (hard) business / customer problems for which it is empowered to discover the best solution, making the new product-range come to life.
What minimum viable structures and processes do we need to facilitate alignment in the organization?
When operating with autonomous and highly empowered teams, we need to ensure a strong alignment and transparency between the teams. Through the Product Vision and -Strategy we’ve already established a strong and common North Star. In addition we need full transparency on the progress in each team.
The company has decided to use the OKR (Objectives and Key Results) system in a disciplined and methodical way to achieve this transparency. Read more about OKRs in e.g., Christina Wodtke’s Radical Focus books.
Implementing a well-functioning OKR practice is a major challenge in itself. OKRs will become the governance backbone throughout the full Product Lifecycle.
At this point in time the primary focus is for the product teams to discover solutions to the business/customer problems. The problems have been defined in a way minimizing dependencies between teams though teams in the network need actively to align and share insights.
What can we do to get the most business value from our combined intellectual capacity?
This creative process of discovering the best solutions to the business/customer problems needs a versatile pick & use toolbox – not a lot of prescriptive processes.
Let’s recap – the objective for this product discovery is to balance the core product risks – before investing a lot in the development of the solutions:
- valuable for the customer
- usable for the customer as intended
- feasible for us to build
- viable for our business
- we’re able to produce the product (in serial production)
In the pick & use toolbox you’ll find e.g., techniques to formulate and test for hypothesis. As discussed earlier, this discovery process for multidisciplinary products is far more complicated compared to single-discipline digital products.
The pick & use toolbox of course also contains a lot of best practices, guides and tools covering all the engineering disciplines involved. Knowledge sharing and -development across the teams is extremely important for the company. It has a number of facilitated cross-teams Community of Practices (CoP). The CoP facilitators ensures the life and dynamics in the CoPs making it as easy as possible for the team-members to participate and contribute. Many elements in the pick & use toolbox are owned and maintained by the CoPs.
You’ll in the pick & use toolbox most likely find several elements from e.g., Six Sigma. Where he company in “the old days” would have prescribed the use of such Six Sigma elements in mandatory processes / check-lists, the company today trust the Product Teams to pick & use the tools most relevant for them.
What can we do consistently to deliver the quality expected by our customers?
The best way to achieve quality is to build-in quality from the start. To that end you might want to pick elements from e.g., Six Sigma like the D-FMEA and have that D-FMEA evolve throughout the product development.
A core theme in Product Discovery is the disciplined design and execution of experiments, testing for a given hypothesis. Some of the Six Sigma elements like DMADV or IDOV could be relevant.
Time-jump - preparation for the 0-series production
We’ve jumped to the point in time where preparations are being made for the 0-series production run of this new product range.
Single-item runs have been made in a production-staging environment resembling the serial-production environment on selected and critical areas. This staging-environment has allowed the teams to validate the design-for-manufacturing and thus the product risk “we’re able to produce the product”.
What minimum viable structures and processes do we need to facilitate alignment in the organization?
The production processes will be automated as much as possible to be run by robots / systems. These processes must have a very high quality and precision. Six Sigma tools like P-FMEA (P for Process) could be relevant here.
The company is, like Tesla, using well-defined DoR (Definition of Ready) and DoD (Definition of Done) for parts / subassemblies. To the extend possible, robots / systems validate the DoR and DoD throughout the production process.
You might want the use e.g., the PPAP tool ensuring that sourced parts will meet DoR.
What can we do to get the most business value from our combined intellectual capacity?
The humans in production will primarily work with programming of robots, QC-systems, logistics processes, maintain DoR / DoD definitions etc. The aim for the company is thus to automate production for several reasons:
- Robots / systems operate consistently with the set tolerances – better than humans
- Robots / systems do not make human mistakes like forgetting to scan a bar-code or provide production data
- Free human capacity for creative tasks not – yet – manageable for robots / systems
What can we do consistently to deliver the quality expected by our customers?
This is again very much about stringent formulation of DoR / DoD including acceptable tolerances. These definitions and tolerances are constantly measured and monitored during production. It could be relevant to apply statistics from the Six Sigma toolbox.
With full traceability the company can trace-back customer-complaint cases to the single product instance and the measurement results for that specific instance. This will again allow for a very targeted course of action if a range of other product instances are needed to be exchanged as a preventive action.
We want these quality checks to be as automated as possible. Realistically though some human intervention can be needed for the final QC release. I’ve e.g., seen that Tesla has a (human) driver take the final car over a series of bumps checking for squeaky sounds (some day this will definitely be automated too).
Time-jump - continuous product improvement
We’ve jumped to the point in time where full series production is running. Because of its strong configuration management and AME combined with heavy data-collection during production, the company has the optimal platform for continuous improvement of its products. Remember, as mentioned earlier, that the company’s production set-up for this product-range is optimized for change using Massively Parallel Concurrent Manufacturing.
And not “only” that, this production platform allows for pre-ordered and customer-specific configurations without jeopardizing quality or speed.
As also mentioned earlier, this product-range needs to evolve radically from its original inception for it to stay relevant in the market. Luckily the company has managed to establish a network of strong Product Teams around the product-range. Together with the Head of Product they keep the Product Strategy updated (and maybe even adjust the Product Vision) making sure the teams are working on the most relevant business / customer problems.
What minimum viable structures and processes do we need to facilitate alignment in the organization?
The most important structures are the Product Vision, the Product Strategy and the OKR system tracking the progress of the problems (objectives) being worked-on by the Product Teams.
What can we do to get the most business value from our combined intellectual capacity?
(Also here) it is highly relevant to have the strong and versatile pick & use toolbox. Such a toolbox and the CoPs across the Product Teams are major elements in the optimal use and development of knowledge. We want to keep process prescription to a minimum viable level not impeding knowledge use and -development.
What can we do consistently to deliver the quality expected by our customers?
The context here is very similar to what happened during our first time-jump, where the network of Product Teams were provided with the initial (hard) business / customer problems to solve.
Solving the continuous improvement problems calls for the same innovation power. The difference now is that we have a product baseline in production to which changes must be made is a very disciplined way. You might be thinking “yes – and it is here we need a significant amount of prescribed processes, check-lists, control-bodies etc“.
Well – no. The Product Teams (being accountable for the Outcome) are fully aware of the quality-aspects. Remember that the Product Teams are stable in sharp contrast to the classic ad-hoc project team. Remember also that the Product Teams are cross-functional, meaning that they also have production technology experts on-board.
Wrap-up
The main take-aways are
- more trust in the Product Teams and less process prescription
- always understand what (objectives) you want to achieve before deciding on the means (which could include the vast range of frameworks, models, standards, tools etc.) – never let the means themselves become the objective (with a few regulatory exceptions)
- formal / prescriptive processes are important and relevant at some stages in the Product Lifecycle – and counter-productive in others – depending on what you want to achieve and optimize for at that stage
- when you feel an urge to define new process prescriptions, check-lists, rules, control bodies etc., ask yourself:
- do we need it – is the added bureaucracy worth it?
- did we fall in the trap letting the means (frameworks, models, standards ..) become the objective?
- how can we maintain a Minimum Viable Bureaucracy?