Telenor’s Stars to Space Stations: An Example of Gate Systems Applied to Product Development

Overview

Telenor built its success in the past few decades on its knowledge of building and running telecommunications networks in developing countries as well as Europe and the Nordics.  It now has a footprint of telecommunications companies in 12 countries with over 175 million subscribers.  With increased competition coming from Over The Top (OTT) providers such as Google and Facebook, Telenor realized that it would need to grow by tapping its potential to develop software products alongside benefitting from its understanding of network operations.  Telenor had started to build several software products ranging from the Bangladeshi video streaming service Bioscope to financial service apps in Pakistan.  However, software development was still a relatively new area for Telenor, and it needed a better system to understand how to make the relevant investments. To address this need, I spent the summer studying the product phase gate process used by companies such as Microsoft and IBM to develop one that worked for Telenor.

Telenor needed to establish a clearer understanding of how to measure progress for early stage product development, and its attempts to use financial metrics were insufficient.  By creating a different set of KPIs for early stage products based around learning instead of financials, this allowed a more efficient use of people and budget (e.g. hiring a user researcher to clarify a customer need rather than spending money on a marketing campaign to get more users on the system).  More relevant KPIs in the early stages of product development thus drove more efficient people and budget allocation for the product process, saving money for Telenor.

Once the system was developed, it was then tested on the products being developed within one business unit. The process for defining and reviewing KPIs as well as allocating people and budget for the product stages was iterated within this group over a six-month period. At the end of this trial, Telenor chose to roll out the system to all business units that were involved in new product development. As the expectations in other business units for product success varied from market to market, the criteria used for promoting products between the phases was adapted for each business unit.

Telenor’s Product Phases

Telenor chose a five stage product development system, with an additional stage to accommodate the information from products that were not to be continued. The five product development stages are:

• Stars – exploratory phase to determine customer need and size of problem
• Bottle Rocket – prototyping stage to address key assumptions in product to determine technical and social viability of a solution
• Satellite – first scalable technical solution, seek to understand technical capabilities at scale and test potential business models
• Space Shuttle – product market fit established, rapid scaling to multiple markets with established business model
• Space Station  - mature product in declining market, seek to make product very efficient; ‘cash cow’ stage

Each stage has a set of clear acceptance criteria, and products that meet that criteria will progress to the following stage.

While the process is shown as linear, the reality is that it is possible for products to go backwards in the pipeline as well as forwards. Changes in the market, technology, problem understanding, or customer base can all result in needing to reevaluate core assumptions about the product offering.

Products were assessed on a regular schedule depending on the phase, with Stars & Bottle Rockets reviewed on a monthly basis and Satellites, Space Shuttles, and Space Stations reviewed on a quarterly basis.  These assessments are called Product Reviews, and are attended by the relevant team members and the person who controls their budget. Product reviews were scheduled for two hours, and from these reviews, decisions were taken to continue the product in the current phase, promote or demote the product phase, or to end the product.  If the product was to be promoted, a separate gateway review was scheduled shortly after the product review to go through the acceptance criteria for the next phase and ensure all questions were answered.

If a product is not able to meet its KPIs at any stage, it is a candidate for the Seedbank.  The Seedbank is a repository of information serving as a base of knowledge for future products.  The intent of the seedbank is to serve as institutional knowledge for product teams across all business units to see what has been tried in the past and use those learnings going forward. 

Telenor Product Review

Product Review is a regular meeting established to compare a given product to the acceptance criteria for that stage and determine if it makes sense to continue.  The product review is a discussion about what has been done in the product so far and what the future plan is.  If the work shows that the product is still a good candidate for meeting the criteria for the next stage, it is continued.  If the product does not show this, the product enters the seedbank and the product team people and budget are reassigned to another product.

The product review is conducted by two senior product managers (typically the Head of Product Management and myself), the product manager, the person who controlled the budget for the team, and anyone else the product manager chose to invite.  While the initial product reviews were conducted by myself and the Head of Product Management, later product reviews could be conducted by any two senior product managers who had been nominated by the business unit and approved by me. Templates were created for each phase to ensure that the key questions were being answered, and checklists were used by the reviewers to assess the completeness of questions.  After each product review, action points would be noted and owners assigned.  These points would be followed up by the senior product managers to ensure that the product manager had the relevant people and budget made available. 

In cases where a gateway review was not needed, actions from a product review tended to be small adjustments.  They would include actions such as finding the right engineer in the Telenor organization to address technical questions or securing time from the legal team to answer a contractual question. Decisions may also include hiring an external user researcher, developer, or designer for a short period of time to augment the existing team or address a specific issue.  For these latter cases, this is why it was important that the budget holder for the product is in the product review so they can approve the spend rather than having to go through another round of discussions. 

In addition to changing people and budget, the scope of the work that is proposed may be changed as a result of product review.  For example, a team believed it was ready to hire a designer to make a series of mockups.  In discussing what needed to be tested, it came out that the hypotheses to be tested were around process, meaning that the product manager herself could conduct the testing without needing a designer.  In another case, the team was ready to spend on a marketing campaign to try to secure more users.  In discussing the state of the product, the decision was taken to invest in further user research to sharpen the understanding of value for the target market before spending on marketing campaigns.  In some cases, the team is unaware of the need for additional people and budget needed for the next phase.  In one case, the team was given security software, people, and checklists to assist in fully evaluating the security implications of a chosen architecture. Another team was given contact information for teams in other business units who had experience in the same area and could offer lessons learned from their experience.

In the case that a gateway product review was necessary, a new meeting would be scheduled and the team would work through the questions on the gateway template.  This template requested specific information such as privacy and legal requirements that may be needed for the next phase.  Later gateways such as Satellite to Space Shuttle may require a great deal of people and budget if approved, so it was important to have the relevant people and budget allocator in the gateway review to approve the allocation, for example, creating new full time employee positions to hire for the team.  The allocator may be a level above or in another department as the regular budget holder for the product.  Given this, it was important that when a product looked like it was going to go through these later stages of review, the higher level person was informed of this upcoming potential need for additional budget and people.

At the beginning, some product teams viewed product review as just an update meeting rather than a decision forum in which people and budget changes would be made.  They saw it as a tax to pay, but were unclear on the benefit.  It took changes in the template and better communication to clarify that this was a meeting in which decisions were made.  This meant that all the relevant people to make those decisions needed to be in product review and they needed to get all the information they needed to make those decisions to progress the product, stop it, or change direction.  Actions from product review were to be followed up to ensure that the product teams were not blocked in delivering on their given KPIs.  Teams were skeptical until they saw that the actions that came from a product review assisted them in their product development. 

Communication of the purpose of product review was the primary challenge of rolling out the system in such a diverse environment.  Each business unit functioned as a separate business, and it took time to track down the correct people, educate them on the process, and then meet with each of the teams.  Learning each business unit and market conditions was also important to ensure that the acceptance criteria for gateways made sense for the products in the local markets.

Iteration of the process was an important part of its success.  Feedback was solicited from the teams after every stage of onboarding, and tweaks were constantly being introduced into the process.  We solicited feedback by running retro sessions with product review participants, asking the managers involved to ask their teams, and asking teams themselves in less formal settings. The templates were rewritten multiple times, and in the end the product managers themselves took ownership of the templates and rewrote them and updated them as things were learned from the product review process. There is still room for improvement as this system develops.  One of the main things we learned was to have a separate set of templates that were used for onboarding a product for the first time to product review, vs an ongoing product review once a product had been introduced to the system.

Allocation of employees and expertise for Product Stages

One of the main benefits of the product stages was setting the expectation around the size of the team and the skillsets needed for the various phases of product development. The guidelines for product stage and team were set so that few people were needed as fulltime dedicated team members in the beginning, and as the problem became more concrete, more budget and more people were added. 

The specific number of people and budget needed were determined by the requirements of the product team as part of product review.  The team proposed the needed people and budget, and the proposal was reviewed by the senior product management and management in the relevant areas to determine if this was sufficient for the expected work.  Assignment of people  came from existing products that may have been disbanded, hiring contractors, or hiring new full time employees. Telenor was only starting with dynamic people and budget assignment, so things went smoothly when the people and budget in question were within the same department, but could be delayed if coming from another department.

Telenor has a goal of more fluid employee allocation from a pool of employees with a range of abilities. With a global product organization, the hope is to have cross pollination of ideas by having employees be able to move locations and product stage work.  With this diversity, employees would be able to develop a range of professional competencies in a truly global product organization.  Particularly in the southeast Asian markets, there is a lack of solid product management and user research capabilities, which means that Telenor has to train its own employees.  With a globally mobile organization, senior product and user research professionals can work for a time in these markets to develop junior employees and gain exposure to new market challenges.  Telenor is in the very early stages of this process so it is too soon to tell definitively how feasible this is.

Gateway Criteria

For each of the five stages, there were specified criteria that the product had to meet in order to progress. These criteria were developed by working with senior management in each business unit to understand their long term financial goals for the product portfolio.  They understand the portfolio theory behind the funnel approach – the space shuttles and space stations had to make enough money to pay for the products that did not make it to commercialization. The senior manager rose to the challenge of balancing long term and short term financial goals to specify the needed criteria for their respective business units.

As Telenor focuses on business to consumer, the early stage criteria for Stars to Bottle Rockets and Bottle Rockets to Satellites require a large addressable consumer population.  From Satellite to Space Shuttle, the criteria instead focus on how much revenue can be earned by the specific product.  In Space Shuttle to Space Station, it looks at the growth curve and determines if there are any large markets that can be addressed with the existing business model.  If the growth curve has slowed due to maturity in the market, it then makes sense to focus on optimizing the business and potentially moving people and budget to earlier stage products that are just ramping up. 

Since telecommunications is a highly regulated business, legal, privacy, security, and reliability in the technical infrastructure are also key elements in promoting a product through the pipeline.  Earlier stages of the product may not need to be technically robust, but they may need to adhere to legal regulations to not cause problems for the parent telecommunications business (for example, certain countries do not allow telecommunications companies to own video content).  By stipulating this as part of the product review process and making the extra check at the gateway review, this reduces the risk for Telenor without hindering the new product development process. 

Planning the Product Portfolio

Aligning the various product initiatives across the business units was also viewed as a part of harmonizing the global product strategy.  To account for this, a system was designed to address rebalancing the portfolio.  However, the first year was spent gathering a baseline of information about the products, so no rebalancing efforts were attempted.  The following is just the theoretical outline of what we would have conducted once the baseline was complete.

Twice a year, a product forum would be held with all the product leaders from each business unit. The intent of the product forum was to review the product strategy and determine if any changes needed to be made to the overall strategy, and to share learnings from the ongoing product development.  In this meeting, the product leaders would share the initiatives they were running and the phase in which each product was. Based on the shared learning, a strategic area may be added, removed, or clarified. 

Four times a year, the innovation forum would be held with all product leaders to discuss the balance of the products in the product pipeline.  Instead of looking at the overall strategy, the intent was to look at the actual products in the pipeline and see if there needed to be any actions to balance the portfolio across the stages. For example, if there were too few new initiatives in a particular strategic area, it may be beneficial to start new initiatives in that area or to make investments in external companies that were at a later stage.  The business units would be able to agree who would take on that responsibility for new initiatives or investments to allow for the rebalancing of the portfolio.

In both the product forum and the innovation forum, the intent was to have the meetings in person with the product leaders. This was meant to foster more of a group cohesion around products and provide them a social identity as a product organization within the global Telenor footprint.  These kinds of links across the company prove critical when it comes to knowledge sharing and facilitating learning between teams further down the organization, since the leaders have a forum in which they work together to build trust.  Working in an organization that is predominantly Asian, meeting in person is an important element of smooth operations between the different units.

Conclusion

At this time, it is too early to report on the results of the Telenor product organization. However, significant savings have been realized through the optimization of budget in the various stages from the first year of rollout alone.  From this past year of product review rollout, the following have arisen as key lessons learned:

• Communication of the system and the value of the system to the right levels of management and product teams is critical for the success of the rollout.
• Understand what the critical outcomes you are designing for and be rigid on those, but be wildly flexible about how those outcomes are achieved.
• Openly and frequently solicit feedback from those impacted by the process.  Understanding irritations and inefficiencies early on allows you to address them in a timely manner.
• When working in new cultures, invest time up front to learn about the culture as this greatly smooths the path forward.
• Ongoing communication to senior management about progress is an important but often neglected element of rollouts.  Be sure to find an efficient communication strategy to report progress in a clear way to senior management.

Whether the early initiatives being taken now will also result in the significant increase in revenues for the future of Telenor is something that can only be judged when the portfolio, like any venture capital investment, has had time to mature. 

About the Author

Lisa Long is the former VP of Product Management and Innovation at Telenor.  She has spoken at a number of events on product management, including Mind the Product, Product Tank London, Agile Scotland, and the Product Manager Festival.