“Ideas are easy, execution is everything.”
– John Doerr, KPCB
– John Doerr, KPCB
The job of a product manager is much more than acting as a middleman between customers and engineers. Product managers are at the nexus of prospects (later, customers), business, technology, and engineering (product design).
Rex Pugh [1], and later, Scott Messenger [2], were two product managers hired to fulfill this critical role for startup Cerent’s Cerent 454 optical transport offering (later the Cisco ONS 15454). Their important job was to provide direction for the product introduction, and its subsequent evolution, particularly in the definition of the “roadmap.”
Consequently, they defined the priorities for employees’ work assignments and the initiatives to be taken. For any startup company, this directly affects everybody. Rex and Scott continuously evaluated the impact each change to the roadmap would have and the associated effort it would take to realize such a change [3]. For the lonely product manager, it was all about priority, priority, priority!
Endless hours were spent taking customer input, sales feedback, and marketing insights as to what the product should be, and must become, to ensure success in the telecommunications marketplace [4]. On top of that time, even more was spent with the engineering and manufacturing teams to negotiate time to implement a feature or build a new piece of hardware. All the while, Rex and Scott had to ensure the cost of goods was minimized and ensure sufficient value was built-in so that the competitive selling price wouldn’t fall too quickly. This, alone, is a delicate balancing act – margins versus selling price. Winning the business, as marketing executives know, is different than “buying” the business.
When Cisco acquired Cerent in late 1999, with this startup operating at a billion-dollar run rate, the Internet giant did not know what to do with Cerent’s product management role. It took Rex Pugh a fair amount of time to educate Cisco on this critical human resource function. Eventually, Cisco understood. Scott Messenger recalls, “They completely accepted the fact that there is a product management organization. They embraced product management and they asked us to define product management. They didn’t have it before Cerent.”
So on top of performing the established role that made the Cerent 454 a “carrier class” product for its telco-centric customer base, Scott had the added job of defining product management for Cisco’s executive team and its human resources department.
“We developed the product management profile for hiring people into Cisco,” Scott notes. He recalls the importance of authoring the roles and responsibilities for his product managers, as the multi-service aspect of the optical transport platform needed clear accountability, but also required strong collaboration with the product’s common functions.
Scott shined to the task of delineating inbound marketing from outbound marketing. “Cisco had product marketing, not product management,” Scott adds. “It was merger and acquisition; that was [Mike] Volpi’s baby. But Cisco didn’t know what product line management was. To Jayshree [Ullal]’s credit, she said, ‘Let’s define it. Scott and his team aren’t product marketing. Product management is product lifecycle and for carriers it’s five ‘9’s and twenty years of lifetime.’”
Cerent’s methodology in managing its product evolution, as this upstart startup defined it, positively helped to transform Cisco. As Jayshree told me in June 2013, Cisco got their money back from the Cerent acquisition “both by entering a new market segment and gaining more relevance in the service provider segment. Today, Cisco is not just an enterprise company because of this acquisition.” Indeed, Cisco became a major player in the service provider segment of the telecom market.
Product managers play a crucial role in helping to transform acquiring companies for the better, in part, by expanding their customer base and enhancing profitable revenue streams.
Cerent illustrated this point.
Consequently, they defined the priorities for employees’ work assignments and the initiatives to be taken. For any startup company, this directly affects everybody. Rex and Scott continuously evaluated the impact each change to the roadmap would have and the associated effort it would take to realize such a change [3]. For the lonely product manager, it was all about priority, priority, priority!
Endless hours were spent taking customer input, sales feedback, and marketing insights as to what the product should be, and must become, to ensure success in the telecommunications marketplace [4]. On top of that time, even more was spent with the engineering and manufacturing teams to negotiate time to implement a feature or build a new piece of hardware. All the while, Rex and Scott had to ensure the cost of goods was minimized and ensure sufficient value was built-in so that the competitive selling price wouldn’t fall too quickly. This, alone, is a delicate balancing act – margins versus selling price. Winning the business, as marketing executives know, is different than “buying” the business.
When Cisco acquired Cerent in late 1999, with this startup operating at a billion-dollar run rate, the Internet giant did not know what to do with Cerent’s product management role. It took Rex Pugh a fair amount of time to educate Cisco on this critical human resource function. Eventually, Cisco understood. Scott Messenger recalls, “They completely accepted the fact that there is a product management organization. They embraced product management and they asked us to define product management. They didn’t have it before Cerent.”
So on top of performing the established role that made the Cerent 454 a “carrier class” product for its telco-centric customer base, Scott had the added job of defining product management for Cisco’s executive team and its human resources department.
“We developed the product management profile for hiring people into Cisco,” Scott notes. He recalls the importance of authoring the roles and responsibilities for his product managers, as the multi-service aspect of the optical transport platform needed clear accountability, but also required strong collaboration with the product’s common functions.
Scott shined to the task of delineating inbound marketing from outbound marketing. “Cisco had product marketing, not product management,” Scott adds. “It was merger and acquisition; that was [Mike] Volpi’s baby. But Cisco didn’t know what product line management was. To Jayshree [Ullal]’s credit, she said, ‘Let’s define it. Scott and his team aren’t product marketing. Product management is product lifecycle and for carriers it’s five ‘9’s and twenty years of lifetime.’”
Cerent’s methodology in managing its product evolution, as this upstart startup defined it, positively helped to transform Cisco. As Jayshree told me in June 2013, Cisco got their money back from the Cerent acquisition “both by entering a new market segment and gaining more relevance in the service provider segment. Today, Cisco is not just an enterprise company because of this acquisition.” Indeed, Cisco became a major player in the service provider segment of the telecom market.
Product managers play a crucial role in helping to transform acquiring companies for the better, in part, by expanding their customer base and enhancing profitable revenue streams.
Cerent illustrated this point.
[1] Rex told me he experienced a revelation while working for Cerent: “Working at HP for so long, we were always in the lab or inside our building and designing and defining products without any real customer touch. We were driven by publication, not driven by a customer telling us what problem we could solve for them. [Working at Cerent] really brought it to light for me, and how terrible a job we did at HP; designing products or developing products that were really innovative, we were following, we were just followers [at HP]. I love the fact that at Cerent we were with customers and that our roadmap was driven by customers. In the end it was customer-driven [product]. It was great. This is how things are supposed to get done. I learned a lot more about that and the structure of what product management should do in terms of requirements, definition, and working with engineering. It was a great experience in that respect.”
[2] Scott began as an “engineer-in-training” with Rockwell Telecommunications in 1986. The company’s ROC-24 product leader, according to Scott, “ was an example of what a product manager should do and not do. Similarly he adds, “ADC’s Cellworx was another example of what not to do. It was kind of the wrong product built right. They had good engineers around it.” For the Cerent 454, he and his boss, Rex, believed the Cerent 454 had the right form factor, a good market environment, and, according to Scott, confidence that “the promise of the architecture evolution of the product was solid.”
[3] The Cerent 454’s roadmap changed with time, as specific requirements waxed and waned. Here are some examples with respect to timing and customer engagement:
[2] Scott began as an “engineer-in-training” with Rockwell Telecommunications in 1986. The company’s ROC-24 product leader, according to Scott, “ was an example of what a product manager should do and not do. Similarly he adds, “ADC’s Cellworx was another example of what not to do. It was kind of the wrong product built right. They had good engineers around it.” For the Cerent 454, he and his boss, Rex, believed the Cerent 454 had the right form factor, a good market environment, and, according to Scott, confidence that “the promise of the architecture evolution of the product was solid.”
[3] The Cerent 454’s roadmap changed with time, as specific requirements waxed and waned. Here are some examples with respect to timing and customer engagement:
Release 1: Essentially, the first release of the ‘454’ was an OC-48-based offering (at 1300 nm) equipped with up to 48 DS3s, supported by 1+1 protection switching and STS1 cross-connections, managed by a web-based browser. OC-3 and OC-12 interfaces operating at 1300 nm were also available.
Release 1.1: DS1 capability was demanded by telco customers and offered as Cerent’s first “dot” release.
Release 1.1: DS1 capability was demanded by telco customers and offered as Cerent’s first “dot” release.
Release 2: The second release was broken up into two releases – 2.1 and 2.2. The “dot-one” release support VT and STS cross-connections, STS-1, Transmux, and basic Ethernet functionality. UPSR and BLSR configuration support was also added for all three OC-n optical line rates. I (R.K. Koslowsky) also drove the need for 1550 nm optics to secure a number of “long-thin” fiber routes, characteristic of regional networks, in spite of the pushback of Dan Jones in engineering, but supported by Rex Pugh.
Release 3: Planned were the OC-192 line rate optics and three ATM UNI interfaces.
Release 3: Planned were the OC-192 line rate optics and three ATM UNI interfaces.
[4] Rex Pugh, commenting on ‘454’ product management, said, “I didn’t want to deal with the tactical issues of execution. [In Product Management], we were going to plan, define, and hand off to the program management and the engineering teams and they all execute the tactical details.” In reference to the backgrounds of some of the hired program managers brought on to manage the details of each new product release, Rex adds, “The marines were good.” On his hires, Rex said, “Messenger came in, the TDM guy. He drove the requirements on OC-192, his first job when he came in. He had so much energy, a bundle of energy. It was great for the team. I brought Chris Rivera on a little bit later and he was helping out to detail Release 2. Chris eventually took on the ‘454’ SONET program and Scott moved up to handle the ‘454’ global platform. We had not yet jumped onto the SDH bandwagon, because it was a whole new shelf design. The [ASICs] were there, the software was there, but it was a mechanical redesign and some ETSI requirements that were a little bit different.” Beyond the evolution of the ‘454’, Rex recalls, “We also talked about building the small ‘454,’ the ‘327.’” Scott replaced Rex, when Rex vested and left Cisco.