Here in part 3 we’ll discuss Renewable Tech [RT]’s strategy for how to bring live to its vision.
Recap from part 2
Part 2 outlined RT’s vision to become a strong Product company thus making a radical shift in the business model from being a provider of customer-specific solutions.
The vision is essentially to build an organization filled with missionaries, working in a strong Product Culture.
Executive summary
Transforming RT from being a solution provider to a product company is, not surprisingly, a complex and difficult challenge. It is a reprogramming of RT’s strong genes:
- From an Output-based business model to an Outcome-based business model
- From a Project mindset to a Product mindset
To make it worse – the transformation cannot be planned up-front, at least not in details, for the simple reason that we have not only a lot of known unknowns, but definitely also a lot of unknown unknowns.
The only sensible way to learn insights, uncovering the unknowns, is through disciplined experimentation. This is why the core of the strategy below is based on experimentation, here in the form of an internal start-up given the name RT-accelerator.
Start small and grow from there
As outlined in part 2, RT is determined to grow a strong Product Culture with one of the traits being a culture of experimentation, which will form the backbone in RT’s strategy reaching for the vision.
- RT needs to protect the current business while at the same time reaching for the vision
- RT is keenly aware of the fact that currently more unknowns than knowns exist on how make the vision come to live thus making a detailed roll-out plan impossible – and counter productive
RT will start by throwing a small stone in the pond – running an experiment – and let the insights and learnings spread from here. This stone will be in the form of an internal start-up.
The internal start-up
The purpose with the internal start-up experiment is make unknows, known, and generate insights thus testing the hypothesis “the vision is viable in RT“.
If the experiment falls flat to the ground, it does not undermine the running business. If on the other hand it turns into a success, it’ll be the most convincing argument for the rest of the organization to adapt.
Running this start-up experiment is like putting on the green in golf. You need the give the ball a fair chance. If you do not hit the ball hard enough, it might not even reach the hole. We thus need to make sure to design the experiment in way that a failed experiment cannot be argued with not having been given a fair chance.
Let’s look at the experiment design ensuring that we hit the ball hard enough … but not too hard. We also need to find a balance between the experiment not being too narrow and not being too broad.
Experiment design
As recommended earlier, we’ll restrict the experiment to one product area: RT expects the area of condition monitoring and predictive maintenance, applying ANI, to grow significantly in the future based on currently not known innovative high-tech solutions. We’ll call the internal start-up “RT-accelerator“.
This is the top-level decomposition of the condition monitoring and predictive maintenance product area:
-
- Physical sensors with site-local control electronics, mechanics, network infrastructure and hardware
- Embedded controller (edge-) software, local 5g IoT and predictable network capabilities
- Cloud-based monitoring capabilities base on e.g., ANI with strong APIs enabling RT’s customers a seamless integration with their relevant systems like SCADA
For areas of importance designing the experiment, we’ll here seek inspiration from the previously presented Innovation Power Wheel.
Innovation Power: Product Culture
Here we’ll discuss how to include the elements from a strong Product Culture in the experiment design.
Product Culture: Culture of experimentation
The rationale behind experimentation is to gain insights and facts / data upon which to make qualified decisions. These experiments will typically fall within the four generic product risks:
- is the solution valuable for the customer?
- is the solution useable for the customer?
- is the solution feasible for us to build and produce?
- is the solution viable for our business?
We do not want decisions to be made by gut-feeling or by HIPPO (Highest Paid Persons Opinion). We’ll insist RT-accelerator to be able to demonstrate insights / facts gained through e.g., experiments and have decisions made on that basis.
RT-accelerator design element: Use fast but well-designed experiments to gain insights / data upon which to make qualified decisions.
Product Culture: Culture of open minds
In RT-accelerator we maintain an open mind for new and better solutions to the problems – without bias on the source of ideas.
RT-accelerator design element: Maintain an open mind allowing innovative ideas for problem solutions thus not getting fixated on one solution. This also is related to dual-track agile having discovery and delivery running in parallel.
Product Culture: Culture of empowerment
We want the Product Teams in RT-accelerator to use an Outcome-based business model meaning that we’ll hold the Product Teams accountable for Outcome. In exchange we’ll empower the Product Teams to find the best solution to a given business / customer problem.
Product Leadership will agree OKRs (Objectives & Key Results), Objectives being the Problem to solve, with the Product Teams.
RT-accelerator design element: Empower the Product Teams to find the best solution to a given problem, and hold the Product Teams accountable for the resulting Outcome.
Product Culture: Culture of technology
As already stated several times, technology is the product. As we’ll return to under organizational structure and servant leadership, Product- and Technology leadership have an important role ensuring the perimeter – including strong technology strategies – within which the Product Teams operate
RT-accelerator design element: The Product Teams must be provided with a strategic context, which includes strong technology strategies.
Product Culture: Culture of business- and customer-savvy teams
As outlined by RT’s executive team in the vision, these Product Teams need to be both business- and customer savvy. That is, serving the real customers and understand the constraints under which the business stakeholders operate.
RT-accelerator design element: The RT-accelerator Product Teams are not only allowed but required to maintain a high-frequency interaction with (potential) customers – directly – with the purpose to test hypothesis / assumptions. In addition, the Product Teams are required to understand the constraints under which the business stakeholders operate.
Product Culture: Culture of skill-set and staff diversity
Covered by the culture of open minds.
Product Culture: Culture of discovery techniques
The discovery techniques are highly correlated to the culture of experimentation. This is about developing a diverse discovery toolbox and about understanding the applicability of each discovery tool.
Marty Cagan’s INSPIRED is filled with such discovery techniques. One particular important technique to master is the “Discovery Sprint Technique”, also known as a “Google Sprint” because it originates from Google Ventures.
We want the RT-accelerator Product Teams not to apply e.g., the MVP (Minimum Viable Product) technique the wrong way. A common misunderstanding is that a MVP is in fact a “Product” suitable for consumption (the phrase “P for Product” in MVP is probably what misleads people). It is not.
What RT-accelerator brings to the market must comply with RT-accelerator’s brand and quality expectations. A prototype / MVP is not meeting these criteria.
RT-accelerator design element: Have the Product Teams, supported by relevant coaching, develop competences in discovery techniques.
Innovation Power: Organizational structure
RT-accelerator is carved-out and getting its capacity from the RT mother-organization. In some areas, like (serial) production, RT-accelerator cannot realistically be self-contained thus needing an appropriate interface to RT’s production facilities. Most of the leadership / management functions can realistically not be allocated full-time for RT-accelerator thus requiring the given leadership / management functions to act in a double role in RT and in RT-accelerator.
We’ll here define the minimum viable leadership / management structure for RT-accelerator to test the hypothesis “the vision is viable in RT”. We’ll return to RT’s role as VC (Venture Capitalist).
Org. structure: CEO, CPO and CTO
In the classic start-up, the founder is also the Head of Product and Head of Technology. For RT-accelerator we’ll aim for a person acting in a combined role as Head of Product and Head of Technology. This could e.g., be one of the directors (with a solid market understanding) in RT’s R&D organization.
We’ll call the combined role in RT-accelerator “CCC“.
Org. structure: Functional managers
The functional managers will have to balance their normal role in RT with their part-time role in RT-accelerator.
Org. structure: Product Manager
Here we’ll operate with one full-time Product Manager [PM] covering all three Product Teams – see Product Team Topology below. As mentioned several times earlier, e.g., here, this is a very challenging role. This PM could be sourced from e.g., the current and classic Product Management area in RT, or from the group of Key Account Managers in RT.
Org. structure: Product Team Topology
Our aim is to have these three Product Teams as decoupled / autonomous as possible, yet highly aligned.
Each of the three Product Teams will be provided with the needed cross-functional competences for the individual team to minimize the dependencies for competences outside the team.
What happened to the project manager – why is that role not mentioned explicitly above?
The short answer is that we’re not running delivery projects in the classic way like seen with e.g., PRINCE2©.
The slightly longer answer is more nuanced. Many of the solid tools found in the project management toolbox are still valuable, used in the right context. The Product Team Template mentioned earlier does not include an explicit project manager role. It does include a Tech Lead, a Scrum Master and a Product Manager (with one of the responsibilities being the Scrum Product Owner, owning the Product Backlog). In practical terms this means that the relevant project management competences are expected in the Product Team. End of the day, the Product Teams are self-organized including the needed level of planning.
Project managers from RT can have different paths into RT-accelerators Product Teams, depending on their profile and interests:
- Product Manager (including the Scrum Product Owner role) if the RT project manager has a strong commercial profile
- Tech Lead if the RT project manager has a technically strong profile
- Scrum Master if the RT project manager is experienced with e.g., Scrum / Kanban. NB – some teams do not need a Scrum Master at all.
- Delivery Manager. In INSPIRED chapter 19, Marty Cagan presents his definition of and rationale behind the “Delivery manager” role:
Delivery managers are a special type of project manager whose mission is all about removing impediments for the team. These delivery managers are typically also the Scrum Masters for the team (if they have that role). They are all about helping the team to get stuff live faster, not by cracking the whip buy be removing obstacles that get in the way.
If your organization is small then it is ok not to have a delivery manager.
Marty Cagan, INSPIRED chapter 19 on The Delivery Manager Role
Note that we’ll not let RT-accelerator be enslaved by e.g., what the official Scrum Guide says about the Scrum Master role. If what works best for en given Product Team in RT-accelerator, is to have the Scrum Master cover some project manager tools / techniques, then it is perfectly ok. We want to have a non-dogmatic approach.
RT-accelerator design element: Carve-out a viable RT-accelerator organization from the RT-mother organization.
Innovation Power: Servant Leadership
What is important to understand is that RT-accelerator uses an Outcome-based business model having the Product Teams empowered to find the right solution to a business / customer problem, but being held accountable for the Outcome.
This is fundamentally different from the classic Output-based business model with (project-)teams being told what solution (from e.g., a feature roadmap) to develop and deliver.
The Outcome-based business model calls for Servant Leadership contrasting the Output-based model with a more classic Command & Control leadership style. The following is expected from the leaders / managers having a (part-time) role in the RT-accelerator experiment:
Servant Leadership: Provide meaning and strategic context
Product- & Technology leadership (called CCC in RT-accelerator) has the important responsibility of ensuring a compelling, inspiring and empowering Product Vision. This Product Vision will act as a common North Star throughout RT-accelerator and support the alignment of the autonomous Product Teams.
Servant Leadership: Provide direction
The Product Teams are given (hard) business / customer problems to solve (note: in contrast to being told what solution to implement). CCC is (also) responsible for the Product Strategy, in essence describing the business / customer problems to be solved.
We’ll use the OKR technique to agree Team Objectives (problems to solve) and Key Results to monitor progress. The use of OKRs is new in RT-accelerator (and in RT) thus calling for some coaching to get started.
Servant Leadership: Enable (real) empowerment
The leaders / managers need to see themselves as facilitators in contrast to their normal command & control mode.
Servant Leadership: Support teams and individuals
This is about coaching, supporting teams to interact, removing impediments and ensuring fast decisions. Included would also be the active facilitation of CoPs (Communities of Practice) across the Product Teams. A future post might take a deep-dive into the nature of CoPs.
RT-accelerator design element: The leaders / managers in RT-accelerator need to train Servant Leadership including getting Product Vision and Product Strategy right. We’ll also need a (minimum viable) process for the disciplined follow-up / review of the Team OKRs.
Innovation Power: Minimum Viable Governance and VC-style funding (also called metered funding)
As other start-ups, RT-accelerator needs funding for its product development. RT will act as the Venture Capitalist [VC] with whom RT-accelerator will seek funding.
The Product Teams will, as would be the case with a “real VC”, have to present a convincing case documenting factual progress and compelling reasons for continued funding. In the initial stages, progress will primarily be in the form of gained insights / learnings.
It would be natural for the Product Teams to use the transparency already in place: The Team OKRs.
Minimum Viable Governance: The Business Case question
In the majority of organizations doing product development, you’ll find product roadmaps based on a prioritization of Business Cases (in its core being a viability calculation based on cash-flow).
When the Product Team is presented with a problem to be solved, it does not (yet) know the solution to the problem thus not knowing the cost to solve the problem or what incoming cash-flow the to-be-identified solution will generate – the basics for the cashflow and NPV calculations in a Business Case. Demanding Business Cases at this point in time would be pure guess-work.
Is what you’re saying that Product Teams in a strong Product company are not using Business Cases?
Depends – in the initial stages we know, what we do not know: the solution to the problem and the resulting cash-flows. In later stages having settled on the solution, it can become relevant to develop a Business Case; especially when large investments are needed.
RT-accelerator design element: We’ll need to define a minimum viable governance & funding process model.
Innovation Power: Minimum Viable Process Prescription and a rich pick & use Buffet
We want to achieve and balance two objectives:
- Have rules of the game presented in clearly understood in prescriptive processes. We’ll do our utmost to have as few mandatory processes as possible.
- Facilitate knowledge sharing and -development. We do this by encouraging the development and use of a pick & use buffet with best-practices in various areas. We want the ownership of this buffet shared among the CoPs across the Product Teams.
RT has for a long time developed a project process universe (for customer-specific solutions) with a lot of processes, check-lists, governance structures etc. – why not just recuse that in RT-accelerator?
Because the existing RT project process universe is built to serve an Output-based business model for customer-specific solutions, optimized for predictability within the “project iron triangle”. See quadrant (C) in the optimization matrix. In contrast we want RT-accelerator to optimize for innovation as depicted in quadrant (A). The two modus operandi are fundamentally different.
But – we do expect some natural overlap, especially when it comes to bringing solutions into (physical) production.
RT-accelerator design element: RT-accelerator is not committed to comply with the existing project process model in RT. In fact, RT-accelerator will focus on building its own best-practices for product innovation and adaptability supporting the Outcome-based business model.
Innovation Power: Technology Excellence
As stated earlier, the basic assumption is that the individuals from RT allocated to RT-accelerator have solid technology insights and experience.
In RT-accelerator we’ll focus on system engineering / architecture as a means to minimize dependencies internally and between teams. This is because such dependencies kills effective innovation and business agility.
The software guys have shown the way for several years with object-oriented designs and encapsulation behind stable interfaces / APIs. We need this notion of encapsulation to permeate the full product, also including the physical dimensions.
This is also known as “contract-first” with contract meaning the interface. The better we get at this discipline, the better we can facilitate teams working towards the same target (staying aligned) and at the same time working autonomously.
The discipline of testing / validating integration interfaces must be an on-going effort not postponed to some “late integration stage”. The software guys call this CI (Continuous Integration).
RT-accelerator design elements: The Product Teams and the functional managers in RT-accelerator need to focus on engineering disciplines allowing a high degreed of de-coupling between teams.
Other experiment design criteria
Experiment duration
Long enough to follow the end-to-end dynamics from business / customer problems to Outcome.
Hypothesis pass criteria
A combined qualitative and quantitative assessment will be developed.
Follow-up and handling of impediments
RT’s executive board maintains a Kanban board with impediments from RT-accelerator with the purpose of quick mitigation and transparency.