Nine Product Management Lessons Learned in Three Years

I’ve been a product manager in the enterprise software space for about fifteen years now (about half my career), and I continue to learn. I spent the past three years, until last month, leading Lightbend’s foray beyond microservices and into products targeting streaming data applications. Here are a few things I learned: 

Lesson 1: Expanding your target market is hard.

When I joined Lightbend, it had recently made the decision to target the streaming data application space, expanding from its core reactive microservice business. Setting aside, for now, whether we had targeted the right product to take to market, the much larger question is whether we could expand the organizational knowledge in this new direction. Two considerations come to mind:

• Building or hiring the right skills, from marketing to sales to support to biz dev.
• Acknowledging how expensive this process is going to be.  

I’ve had a long held belief that you don’t try to expand your target market until you’re an established leader in your existing target market. And being an established leader includes sustaining a cash flow that allows you to invest in the expanded market. If you don’t have a sustainable positive cash flow, you will end up diluting your investments across two markets, instead of sufficiently investing in one.

Lesson 2: Early success is critical.

Early success provides a virtuous feedback cycle. This is true for both product and market development.  

For product development, early successes allow you get the feedback on what customers value and need from your product. It is the strongest input into sharpening your product focus and priorities. This will be echoed in the lesson about the importance of addressing developers in your target market.

My old boss on Coherence, Cameron Purdy, taught me the following mantra: Build great products, help to make your customers successful, and then tell the world about it. Maybe you’re not as dumb as me, and absorbed this crucial, simple lesson in the first six months of being a PM. For me, it took seeing the dynamic of experiencing “early failure” to realize how crucial “early success” is. Consider what happens with even one early success:

• It provides confidence to the sales team that your product can be sold.
• It provides a template to the sales and marketing team for how to sell the product.
• It shows customers that they are not “first mover”, i.e. your product appears to be a safer bet.

Without early success, you risk alienating sales and marketing, and without their help, even the best products will languish.  

Failure to achieve early success does not mean that you built a bad product. The point is that as a product manager, you have to make it your number one job to achieve those first successes.

Lesson 3: Open Source is the only business model, and it’s hard.  

Call me one of the last holdouts. I’ve fought against the open source software (OSS) model for a long time as a business model (well, for all but Redhat), and my primary argument has been that an OSS model is necessary for adoption, but is it possible to make money using an OSS model? Well, I don’t believe the argument matters anymore. Developer-oriented software will not be adopted at all unless it’s OSS. It won’t be downloaded; it won’t be trialed. And improving non-OSS software takes much more investment. So I’m done arguing against it.  

But Open Source models still present enormous challenges. The old model of Open Source core with proprietary add-ons doesn’t seem to work. It’s amazing what customers will put into production today. I’ve seen customers take on higher risk if the solution solves some problem for them at a minimal cost. This includes security risk and operational risk. It is nearly impossible to sell “enterprise editions” with proprietary value-add features, though customers will buy support. In part this is because proprietary value add implies some degree of vendor lock-in, which customers are more and more cognizant of. If you are asking a large customer to trust that your relatively small company will be around forever to support the usage of your proprietary software, or to trust that an acquiring company won’t jack up prices, you are expecting too much.  

The best way to monetize software today is by offering it as a service. Customers will pay you to take on the pain and the risk of hosting and operating the software. It is something they would need to do anyway. (But it is not hard to see the demise of even this model, as operations get codified in Kubernetes operators. In some cases, OSS vendors produce proprietary operators, while free alternatives appear from third parties. Ultimately this may lead to a competition in “Who can host a service most efficiently?”

Lesson 4: It’s all about developers.  

Times have changed dramatically over the thirty-plus years I’ve been in the industry. When I started my career, the motto of software purchasing departments was that you’d never get fired for buying Big Blue. And while it’s certainly true that big vendor relationships, as exhibited by the likes of IBM and Oracle, smooth the path to software sales, more and more usage (and eventually, sales) are driven by developers making their own choices. This has many causes, with open source, migration from monolith to microservice architecture, and cloud services being three of the main ones. (Why the cloud services? This is something I learned from a customer recently: If your service is billable through a cloud vendor for whom the customer has a pre-approved budget, then a developer can use that service without the barrier of obtaining a separate budget approval. That is a fast track to sales for your product, and puts power in the hands of the corporate developer.)

In lesson 2, I spoke about the virtuous feedback cycle of early success. The same applies to early developer feedback. Getting early releases out into the community has many benefits;

• Free early testing and feedback
• Early usage and roadmap direction
• Free development and marketing

When we open sourced Cloudflow at Lightbend, it surprised me how many people wanted to contribute to the project, for myriad reasons. Some were using the product, but others found it interesting and just wanted to make a name for themselves, build their résumé, or cut their teeth on an open source project. This takes significant work -- both architectural and management -- but is well worth it to build a loyal developer community.  

It’s also worth exposing your work early to get feedback, and perhaps again, to find unexpected help in finishing a feature. 

Lesson 5: Being late won’t work, being early is expensive.

Timing the market is impossible to do, and I don’t really advise trying it. If you see a problem that needs solving, you can bet other people see that same problem. Just how big that opportunity is, of course, and whether it merits investment, is your next bit of homework. But the problem is there to be solved.  

The challenge I ran into at Lightbend was very particular, but can be generalized to any solution that depends on an ecosystem. At Lightbend, we were building a product that, to stand together, should be built on a modern cluster container scheduler. YARN didn’t fit the bill, and the choices were kubernetes or mesos. At the time of decision, kubernetes was not yet ready to run the full scope of frameworks that would be part of our product, and mesos, though immature, seemed further along. We chose mesos. We all know how that decision went, and the team wasted almost a full year rebasing to kubernetes. So much for early success.  

(Corollary: making decisions based on non-product factors, like partner strategy, may be very good for business in general, but probably not for the specific product. It should never be done early in a product’s existence - unless it’s the reason for the product in the first place. We may have made the same choice to baseline on mesos anyway, but our relationship with Mesosphere certainly helped tilt the scale early on.)

Lesson 6: When your engineering team questions your product’s value, it’s time to reassess.

For crying out loud, I should not have to say this. But I blew it. For about the first year on the job, members of the engineering team continually questioned the direction of the product that we were building at the time. Not just routine arguments like “Which feature is more important?”, but more fundamental questions like “What does our product do? How does it help the customer?” Now, of course, management thought we knew the answer to those questions, but still there was enough dissent among senior members of our team to suggest we didn’t fully understand the questions.  

We encouraged a culture of “Disagree, but move on”, and some of the engineers could not simply move on. This should have been a huge warning to us. In addition to these noisy engineers being right in the long run, which resulted in us shifting investment to Cloudflow, the failure to address the engineers’ concerns hurt the team’s productivity and delayed the necessary corrective actions within the business.  

Lesson 7: It’s ALL your responsibility.

The old adage that the product manager is the CEO of the product is true, even if the org chart doesn’t appear to agree. The PM is ultimately responsible for marketing plans, sales execution, product engineering decisions, training programs, and everything else. We don’t actually do most of these things ourselves, but we must make sure they are getting done, and done well, and on time.  

I have always had a core belief that I work with professionals, and so I can trust that they will get the job done. And that has almost always been the case. But not always. In some cases, whether it is because of budget shortfalls, personal crisis, or lack of comprehension (see lesson 1), some jobs will not get done according to plan. Placing blame does not matter; what does matter is that if you want your product to be successful, you must take full responsibility for corrective actions. Again, not by stepping in to do someone’s job for them, but by helping them through the situation and helping them get the resources or training they need to be effective.

Lesson 8: Over-communicate.

No matter how many documents i wrote and shared, how many conversations i had, how many meetings i joined, field organizations, engineering, partners, they all came back to me with questions i felt i answered a million times. Do we support python? Do we run on GKE?  

This isn’t their problem for not listening or understanding. Everyone’s attention is pulled in a million different ways. And we also have a million ways to share information: slack, email, google docs, meetings, water cooler. And we are distributed and time-zone challenged. Just like lesson 7 says, it’s all your responsibility, and if a message is not getting through, it’s up to communicate again and again, and in different forms, until it does.  

And let me end on one I already knew:

Lesson 9: PMs need great product teams to build great products. 

You can be the best PM around, but ultimately you will need a great engineering team to make the product a success. Developers can sniff out the carefully crafted product from the quickly glued together one. Throughout my career, I've had the fortune to work on some truly great products: Bell Labs Tuxedo and Unix, WebLogic, Coherence are some of the names that have all survived more than twenty years in this fickle industry. I can name key engineers on each of these products without whom, having set the early tone for engineering standards, none would have enjoyed their lasting competitive advantage.  

So, be humble, and realize your limitations.