Four Lessons I Learned As a Young Product Manager that Still Guide Me Today

Greg Coticchia


Early in my career I worked with a great fellow product manager, Greg Strouse, who became a lifelong friend. As both our careers progressed, Greg used to tell me that no matter what new jobs or roles we took on, we could always go back and be product managers, and that it would be fun. I still agree with that thought in many ways because I don’t think I ever stopped thinking of myself as a product manager, no matter what role I actually play in a company.

When I worked with Greg in the early days of the software market — almost 30 years ago—I had the great opportunity to work on several enterprise software products, all with different market challenges and at different product life cycles. We had the classic ‘Boston Consulting Group’/BCG cash cow products, and questions marks, and stars, as well as a few dogs. Owning and managing a portfolio of these products formed many of the lessons learned that I apply to building other products, programs and even companies. One in particular, AutoMate, an early stage enterprise data center automation product and later market leader, taught me a lot about product ‘go to market’ strategies.

Here’s a few lessons learned:

1.) Domain Expertise is Overrated. 

As a young PM, my job was profitable top line revenue growth. I needed to find other products that would form a suite of high growth (better than CAGR 35%) offerings. Internally we also competed for resources with other product groups, and if we couldn’t show the need for those resources, we would be left behind. So we were competing internally and externally. And the automated operations market came along. It changed everything. I had worked in the factory automation (EATON Cutler-Hammer and then Gulf & Western/Eagle Signal Controls) business straight out of college, as a sales engineer. So I knew the pluses and minuses of marketing automation, and ‘unattended’ and ‘lights out’ messaging to a different marketplace. However to sell this to information technology people would be different—yet the same.

Lesson: Use your experiences from other marketplaces/verticals/segments and hire people that have them.

If I had simply worked in information technology (I.T.) industry, I wouldn’t have had the advantages I brought to the market. This goes to hiring for domain expertise. It’s not always necessary or good. Sometimes having different market experiences is key to competitive advantage. So stop hiring someone who comes from ‘our space’ or thinking they are better because of their domain expertise. They may not be, and they may bring boundaries of what’s possible that actually constrains your capabilities.

Again, I was able to use the lessons from the factory automation marketplace and apply them successfully to the data center automation market. It was like I had seen the movie already and knew the outcome. It was ‘Groundhog Day’ in many ways, and I knew how the ‘day’ would play out. Competitive advantage my not come from where you expect, or the obvious places.

2.) Differentiate, Don’t Catch Up. 

Our product was behind in the market when we launched for a variety of reasons. We were in the classic ‘losers’ quadrant of the Gartner Magic Quadrant. We had our work cut out even knowing what we had to do (see #1) to win. So we had a decision to make, given like all companies, where do we put our resources? If we didn’t start winning i.e. revenue and customers, the company would place its bets in other markets and with other internal teams.

We decided to place a bet on differentiating functionality rather than catch up on base functionality. This was a huge risk. Would the differentiation be valuable enough to overcome the base functionality that competitors had? And if we were successful, what would we do next? Would we further extend the differentiation, to then go back and use the advantage to ‘catch up’? These were all strategic product questions we had to play out as we tried to decide how best to play the chess game of product marketing.

We bet big on the differentiating feature—a capability that allowed the product to integrate to a variety of existing tools and pieces of data. It turned out that it did have enough value to drives sales and give us time to catch up with base functions. Different was better. It also put us in the Leaders quadrant of the next Gartner Magic Quadrant.

That’s not to say this works every time. It was a bet that we won. If the differentiation hadn’t had such unique significant value, we probably would have lost. But as Eminem sang “Look, if you had one shot, one opportunity to seize everything you ever wanted, one moment, would you capture it or just let it slip?”

We captured it. Big time. And the product became one of the market leaders and largest revenue producers for the company for years.

3.) Poison the Salesforce One at a Time. 

This is for B2B sales geeks. A salesforce is your ‘first’ customer. If your product doesn’t ‘fit’ into their bag, if you can’t show them how to make money with your product, relative to other things they can sell to make their number, your product will never get out of the bag. And even with the best, most differentiated product, you will lose. You need your salesforce to get to your customer. So sell them. But HOW you sell them is important too.

Just like when you do a ‘soft launch’ or a ‘beta test’ with early customers, you need to do the same with your sales team. In the words of an old friend, Paul Johnson, you need to ‘poison’ them one at a time. What does that mean?

Most likely the salespeople that can pay attention to your new product as it launches are the ones who aren’t making their numbers, who are willing to take a risk on something new, because they aren’t selling what’s available now. And the ones that are making their numbers or blowing them out, are selling other stuff successfully—why would they sell something new? You need to get in their bag. So just like customer segmentation, target your salespeople you want to sell your product. Work with them closely. Make them successful. Make them a referenceable salesperson that other salespeople think’ ‘Hey, they are making money selling ‘X’ product; I’ll give it a shot’

Poison them. One at a time.

4.) Go Wide Not Deep.

Everyone loves the idea, or even the reality, of full-featured, robust capabilities in a product. But in many cases you can’t, or shouldn’t, develop them. I like to think the best way to do most features is to define the minimum set of functionality that demonstrates the capability. No more or less. Think of it as rev. 1 of the feature. You will get more chances to build it out. And just like a Minimum Viable Product (MVP) has just those core features that allow the product to be deployed, and no more, you need to think of individual features that same way. Start small, and then get feedback. Test ‘sale-ability’ of the functional/feature; get prospect and customer feedback. If you build it out ‘all the way’ in the first release, you have poured too many resources in one area. That’s too big a risk with little market feedback.

Going back to my earlier example in section #2 of this blog, when we released that key differentiating feature, we didn’t develop a lot of new functionality; we used existing code without modifying it from another product we sold. And once it drove sales, we refined. If we had spent the time to develop the code from scratch and make it picture perfect, and the idea had failed, we would have spent a lot more money and been even further behind.

I could easily write dozens more lessons after these four lessons from this job that guide me today as well. It was a great experience being a young product manager at a company with multiple products in different lifecycles, but overall in hyper-growth mode. I learned a lot that I continue to apply through my career. And Greg is still right; being a product manager is fun.