Wednesday, February 26, 2020

Product management playbook 1

My first passion, and my first job before technology strategy is product management. While these two occupations are naturally intertwined, I miss the satisfaction of defining, curating, polishing a strategy, requirement sets, value proposition, positioning and see these finding their market fit.

I have recently helped a few tech companies in establishing or reinforcing product management functions in their organization and I thought I could share some of my playbook.


The roles of the product manager

Traditionally, product management functions are introduced in technology companies as soon as a structured process for receiving, categorizing and prioritizing market inputs to development teams is necessary.
A start up might develop a product or service based on its founder’s vision, but as soon as the value proposition is confronted to potential clients, new requirements emerge, gaps are identified and it becomes necessary to categorize and prioritize all these competing inputs into a coherent framework that facilitate the decision making process.
Product management is the result of scarcity of resources (engineering, hardware, software, time, investments…) and the ever-growing list of potential application of a new product or service (new clients, new geographies, new application, new market segment…).

The more interactions between the company and the market (clients’ meetings, competitive announcements, standards and technology evolution…) the more opportunities are identified for enhancing, evolving, adapting the product or service.
As the product matures, it invariably as well accumulates a technical debt, product of design and architectural concessions or compromises for time to market. This technical debt is a risk to be managed closely. As time goes on, the amount of correction, re architecture, rework that is necessary to correct a faulty initial design becomes extremely punitive.



The product management is responsible for knowing at any time, what the market needs, what the product can do today, what gap exists between these two positions and the level of risk the company is committing to when answering a RFP where gaps with the current offering exist.

How to prioritize requirements?


Every commercial company would like to think itself as market, sales or client oriented. Satisfying the client is the best and fastest way to generate commercial success. Unfortunately, there are many clients that do not know what they need, or that want something that is not what you can provide or that need you to adapt your offering to their proprietary environment to a degree that would make that product version only usable by them.

There are also companies that are differentiating through innovation, essentially creating a new product or market category. In that case, prospects are not necessarily the best guide for developing the product roadmap.

Technical debt is traditionally not a concept that sales or upper management want to concern themselves with. “Losing” time re architecting a product to deliver the same functionalities as today with months of delay can be perceived as a waste of time and commercial opportunity.

Evolution of standards, technology or competitive announcements have variable effect on the urgency to develop a feature vs. another, and the difficulty here is that the information is always imperfect, incomplete and requires a lot of analysis and experience to right-time the investment.
Bugs, errors, failures are always critical to solve when they affect a customer and their revenues, deciding on a workaround, a fix or a redesign is complex and requires a good grip on what the engineering team can produce and what to trade from the roadmap to deliver this.

These four examples are but a few of the decisions that a product management function have to grapple with. As a result, product management is unlikely to satisfy everyone. As the gatekeeper for product decisions, it interfaces with all the key functions in the enterprise and its decisions have an effect on all of them. For this reason, it is key that product management is completely aligned and supported by the management team and the CEO. 

Product management in the company

 The product management function is essentially a decision function. It must evaluate the market, the capacity of the engineering team and find the best market-fit for its product. It must be able to

  • create a value proposition, positioning and message for its product that is aligned with the company positioning and the market
  • translate market requirements into product, architecture and technology requirements,
  • create documentation and collaterals for sales support (brochures, infographics, white papers, business cases, presentations, demos…)
  • negotiate with clients, sales and sales support the roadmap, features, requirements, functional specifications, availability
  • negotiate with engineering the design, features, options, and availability
  • report to management team the product profitability, market position and market share…
  • Because of the range and variety of decisions involved, the product management function must traditionally report to the CEO, to ensure perfect alignment with the company vision, mission and priorities and to guarantee equal footing in negotiations and escalations resulting from its decisions. Because few in the company will know as much about the product, from a technical, strategic and commercial perspective together, product management is a position of trust and responsibility.

For these reasons, it is important that the methodology for receiving and cataloguing market inputs, translating and categorizing requirements, negotiating and recording results of discussions, communicating and reporting internally and externally be transparent, well understood by the management team and underpinned by strong processes.

Sunday, February 23, 2020

Telco growth: my objectives, vision, tactics, doctrine at Telefonica




As mentioned in my previous post, telco transformation through innovation and connectivity control requires a strong framework to guide the decision-making process. Here is a list of objectives, vision, strategies, tactics and doctrines that guided me through my time at Telefonica. I believe they can be adapted to many operators’ situation and organization to generate value through successful launch of new connectivity products.

Objectives:

  • Fast creation of new products and services by systematically leveraging economies of scale, reusing modular technical solutions and automation.
  • Creation of a toolbox of technological tools, operating models, best practices, documentation, blueprints, tests and certified solutions...
  • Deliver complete products, not just technology, but also operating model, suppliers value chain and devops teams...
  • Facilitate the transition from innovation to business
  • Systematically evaluate new technologies, suppliers in the laboratory and in the field
  • Fulfill our ambition to transform the industry


Vision:

Create a sustainable commercial growth factory for the company through the systematic research, implementation of services and products that achieve strategic, tactical, commercial, and technological advantages based on the network such as infrastructure or connectivity as a service.

Strategies:

  • Explore and classify services, market trends, competitive and direct and indirect movements and their technological evolution to identify risks and opportunities to create/destroy value for the company based on the network as infrastructure or connectivity as a service.
  • Creation or integration of network and IT technologies to disaggregate and control the cost structure of the purchase, implementation and deployment of connectivity functions and services.
  • Choice and implementation of disruptive connectivity services, products or businesses by designing the E2E value chain
  • Transfer of technological parts, services, products to commercial teams ready for production
  • Systematic identification of differential competitive advantages for the company and strategies to achieve their implementation
  • Implementation of innovative work and development methodologies, especially aimed at creating a DevOps/continuous development/continuous testing model for network technologies and connectivity services


Tactics:

  • Systematic disaggregation of high-level commercial systems and products of network and IT integration to identify manufacturers, intermediaries, sources of savings and their organizational and process impact
  •  Systematic prioritization of open source for MVPs, to learn the state of the art, limitations and development and integration needs
  • Projects, products, technology parts delivered with operating model, manufacturers / integrators / ecosystem developers
  • Identification and implementation of critical paths to deliver to the customer as fast as possible (MVPs, early prototypes deployed in commercial networks)


Doctrine:

  • Customer first
    • Development of services, projects, products with priority to the voice of the customer and the business over technology
  • One size does NOT fit all
    • Resist the model of trying to implement the same technology, solution, manufacturer for all parts of the network and all situations. Specification, design and development of technological and commercial solutions that are infinitely modular. Nothing monolithic, so that we can adapt the solutions to the realities of each market / segment
  • Always open
    • Technological development based on open models (APIs, standard and published interfaces, ...)
    • Open Source, wherever possible
    • Multi manufacturer and no lock-in by design
  • Modular, serverless when possible > micro services > containers > VMs > VNFs > PNF
  • Availability, generosity, active collaboration with commercial teams, third parties and transparency of communication
  • Systematic use from the design of
    • Data science
    • UX
    • Security
  • Agility, speed and results
  • Planning, development, iteration, continuous deliveries
  • Hypotheses, design, development, testing, ... Repeat
  • Pivot fast
  • Take calculated risks
  • Stop activities that fail to meet objectives
  • Organizational flexibility for team members to have diverse and multi-project responsibilities, and can also change during the life cycle of each project
  • Self-management and organizational structures with minimal hierarchy
  • Simple and cheap
  • Systematic simplification of legacy
  • Good enough, cheap > >  over engineered and expensive
  • DevOps
  • Continuous development



If you would like more details, feel free to reach out, I have developed an innovation / transformation workshop to put in practice some of these strategies.
Also available:

Thursday, February 20, 2020

Telco relevance and growth

I am often asked what I think are the necessary steps for network operators to return to growth. This is usually a detailed discussion, but at a high level, I think a key to operators' profitability is in creating network services that are differentiated.
I have seen so much value being created for consumers and enterprises at Telefonica when we started retaking control of the connectivity, that I think there are some universal lessons to be learned there.

Curating experiences

Creating differentiated network services doesn't necessarily mean looking at hyper futuristic scenarios that entail autonomous drones or remote surgery. While these are likely to occur in the next 10 to 20 years, there is plenty today that can be done to better user experiences.
For instance, uploading large files or editing graphics files in the cloud is still slow and clumsy. Also, broadband networks' advertised speed has become meaningless for most consumers. How can you have a 600mbps connection and still suffer from pixelated video stream or a lagging gaming session? There are hundreds of these unsatisfactory experiences that could benefit from better connectivity.

These nonoptimal experiences can be where operators can start creating value and differentiating themselves. Afterall, operators own their networks; since they do not rely on the open internet for transport, they should presumably be able to control the traffic and user experience at a granular level? A better connectivity experience is not always synonymous with more speed, in most case it means a control debit, latency and volume.

Accepting this, means that you have to recognize that the diktat of "one size fits all" is over for your network. You cannot create a connectivity product that is essentially the same for everyone, whether they are a teenage gamer, an avid video streaming fan, an architect office, a dentist or a bank branch. They all have different needs, capabilities, price elasticity and you can't really believe that your network will be able to meet all their needs simultaneously without more control. Growth is unlikely to come in the future for everyone paying the same price for the same service. There are pockets of hyper profitability to extract, but they need a granular control of the connectivity.

"Vanilla" connectivity for all will not grow in terms of revenue per user with more general speed.

Being able to create differentiated experience for each segment  means certainly being able to identify and measure them. That's the easy part.  Operators mostly have a good, granular grasp on their market segments. The hard part is finding out what these segments want / need and are willing to pay. The traditional approach is to proceed by creating a value proposition, based on a technology advance, test it in market studies, focus groups, limited trials and trials at scale before national launch.

While this might work well for services that are universal and apply to a large part of the population, identifying the micro segments that are willing to pay more for a differentiated connectivity experience requires a more granular approach. Creating experiences that delight the customers is usually not the result of a marketing genius that had it all planned in advance. In my experience, creating, identifying and nurturing this value comes from the contact with the client, letting them experience the service. There are usually many unintended consequences when one starts playing with connectivity. Many of successful telco services are the fruit of such unintended consequences (texting was initially a signalling protocol for instance).

Programmable networks

One way to create and curate such experiences is to increase your control on the connectivity. This means disaggregate, virtualize and software-define the elements of your access (virtualize the OLT and the RAN, built a programmable SDN layer).
You should accept that you can't a priori really understand what your customers will value without testing it. There will be a lot of unintended consequences (positive and negative). It is therefore necessary to create a series of hypothesis that you will systematically test with the customer to validate or discard them. These tests must happen "in the wild" with real customers, because there are invariably also many unintended consequences in deploying in live networks with real population compared to in a lab with "friends and family" users.
In average, you might need to test 50-60 variants to find 2 or 3 successful services. In telecom-years, that's about 100 years at today's development / testing cycles. But if you have a programmable networks, and know how to program, these variants can be created and tested at software speed.

Therefore, you need to test often and pivot fast and you need to be able to test with small, medium and large samples. The key for this is to build an end to end CI/CD lab that is able to coarsely reproduce your network setup from the core, the access and transport perspective. It needs to be software defined with open interfaces, so that you can permutate, swap and configure new elements on-demand.

Since current networks and elements are so complex and proprietary, you need to identify greenfields and islands of wilderness in your connectivity where you will be able to experiment in isolation without disrupting your core customer base. At Telefonica, these uncharted connectivity fields were rural networks and edge computing, in other networks, AI-augmented networks operation, network slicing or 5G could be perfect experimentation grounds.

Pluridisciplinary teams

Another learning is that not integrating user / customer feedback at every stage of the elaboration of the service is deadly. It is necessary that UX designers be part of the process from the inception and throughout. They might not be as heavily involved in some phases (development) than others (inception, beta, trial...) so they can be shared across projects.
Increasingly, data science, security and privacy good practices need to be considered also throughout the projects pivot points. In many cases, it is difficult, expensive or impossible to retrofit them if they were not part of the original design.
Products and services do not necessarily need large teams to take off the ground and create value, but they do need dedication and focus. Resist the temptation to have the core team work cross-project. What you gain by identifying possible synergies, you lose in velocity. Rather have small dedicated teams with core members and specialists that are lent from project to project for periods of time.
Foster internal competition. Evaluate often and be ready to pivot or kill projects.

Paradoxically, when you find a successful service, in many organization, the phase in which these projects are most likely to die is when transitioning to the products and business teams. The key is possibly for these not to transition. I have long advocated that it is easier for an operator to launch 5G as a separate company than as an evolution. But it is impractical for many operators to consider starting a parallel organization for network transformation.These innovations, if they are to transform the way the networks and services are managed must be accompanied by a continuous training process and a constant resource rotation between innovative and live projects. Therefore transformation and innovation is not the work of a dedicated team, but of the whole workforce and everyone has opportunity to participate in innovation projects, from inception to delivery.


Beyond the "how", the teams need a clear framework to guide them in their daily decision making. The "what" needs to be oriented by a vision, strategies, tactics and a doctrine that will explore in a subsequent post.

Please share your experience with transformation and innovation projects in the telco world. We all grow by sharing. "A rising tide lifts all boats".

Interested in how these principles were applied to the creation of the Open RAN market? contact me for a copy of the report "xRAN 2020".