TLDR: Net Promoter Score℠ surveys can hold valuable clues for how to improve your product and better manage your product roadmap. You’ll need a structured approach to turning those clues into actionable insights and changes that result in improved customer retention. Here’s a 4-step guide to getting the most out of NPS surveys. Continue reading
On Product Management
A proud day: shipping a net-new product that just works
My former team at AVG just launched AVG CloudCare.
CloudCare is a managed services platform that enables local IT resellers to become managed services providers to their small business customers. This article did the best job of describing the great value proposition for security and IT support, for resellers and customers alike.
A lot went right in getting there. The product was rooted in a clear and well-thought-out strategy. We made a directed investment in building it from scratch. We focused on a customer segment that was under-served by existing solutions. A lot of research and interviews went into understanding both the customer and resellers’ needs. And it got tested and refined in partnership with our users along the way.
Congrats in particular to Mirek, Vikas, Alan, Darren and David. You pulled off something special.
My hero, the Software Architect
In my many years doing product management or managing the function, the number one blocker to getting the features I want (and the user needs) is……software architecture.
Reading Mike Driscoll’s recent blog on software craftspeople reminded me that this architecture topic has been stewing in my brain for a while now. Time to write about it.
“Too hard”, “too complex”, “too long” are the persistent reasons behind engineers’ resistance to feature requests or major product pivots. What I realized is that in every case, it was the software architecture holding us back. More specifically, the lack of componentization and modularity.
And the pattern spans every experience I’ve had; across lots of different products, across lots of different market sectors, across lots of different architectures (from client-side tools to client/server apps to SaaS/cloud apps), and across lots of different company sizes (pre-revenue to behemoths like SAP and EMC).
Need a new UI presentation tier? Sorry, that code is co-mingled with the underlying business logic. Need a new data management tier? Sorry, the file system is bound to the rest of the code. Need new business objects to show up in the schema? Sorry, we can’t split our giant table and it’s already too big to extend.
One can understand how this predicament arose. When new products are built, what’s required is focus on solving the user problem at hand. You don’t have time nor money to design for unknown needs and future flexibility. So why pay for abstraction and modularity without any present-day reason?
The bigger problem is when products mature and the user needs outgrow or diverge from the capabilities of the original architecture. What to do next? Re-factor and modularize? Re-build from scratch? Limp along by stuffing new features into the code but with huge effort each time?
Nobody knows the magic formula for how to make these decisions. Re-factoring scares the crap out of engineers lest they “break something”. After all, by the time this discussion arises, you’ve got spaghetti for code. And the folks who wrote it might not be around anymore.
Re-write scares the crap out of the business leaders, since it appears to be paying twice for the same product. And there’s the inherent risk of missing deadlines. Oh yeah, and you just put your legacy product version on life support so you can afford to staff the engineers on the re-write project. And you’re losing ground to competitors along the way, since you’ve stopped new feature development to pay for a better architecture.
No wonder products whose architecture devolved to something bad, or started that way, never get fixed.
This vicious cycle is what creates the opportunity for “innovation” in the form of a start-up who has the benefit of a clean sheet of paper: fresh, elegant code using state-of-the art languages, components and tools. That seems like a wasteful way to solve the problem.
Enter the architect. If you have a great architect, every problem is reduced in magnitude.
With a great architect, new products have some modularity and flexibility designed in. A little bit of future-proofing goes a long way. Existing products can be selectively modularized and modernized so the new functional capabilities are delivered without breakage. And if the time comes for a re-write, you have confidence that all of the lessons learned from the legacy code base are applied to the new design. Thus, a greater chance of success, especially in meeting a deadline.
So, what makes a great architect? In many respects, a lot of the same characteristics that make a great product manager: curiosity, an ability to translate what users and salespeople need into technical terms, abstract thinking that enables one to imagine new possibilities, etc. Of course, the architect also needs the deep technical experience too.
Back to the premise of Mike Driscoll’s article: the best software is being built by people with, dare I say it, experience. Experience to avoid pitfalls because she messed something up before. Experience to choose the right tools for the job, much like a fine craftsman that builds furniture, or houses, or bespoke clothing. Experience to know what degree of flexibility to design in, without paying for needless flexibility that feels more like insurance against every conceivable future requirement.
I’ve known some good architects and probably only one or two great ones. With the great ones, we have had some huge debates thanks to the force of personality that seems to come with great ones. But in the end, despite the strong personalities, great architects are worth having. And the great product companies know this, which is why they spend a lot of money on great architects.
I say it’s money well spent.
Where do Product Managers come from?
I was reading the interesting but flawed article on Techcrunch about “product guys”. As in, Product Managers. Let’s at least start with the right title. Cripes.
One of the author’s contentions was that good product managers must have coded in their past, in order to properly collaborate and empathise with their engineer co-workers.
This assertion made me think about where good product managers came from.
The first answer is that product managers don’t come from product management. As in, there is no university degree for product management that is a mainstream path into product management as a job. (Yes, there are a handful of product design degrees, but sadly at present a tiny portion of product managers carry this pedigree.)
Therefore, product management is more of a trade, with the apprenticeship starting elsewhere. Good product managers come from many places.
In enterprise software, pre-sales engineers are a common path to product management. Why? They spend all day demonstrating their products and even deploying them in customer environments. Maybe pre-sales engineers get so frustrated with the product that they want to take it upon themselves to fix the issues. It’s also the case that pre-sales travel can burn you out, for which a headquarters job can be appealing.
Product managers can also come from customer care. People who spend all day troubleshooting users’ issues can develop an acute sense of what product features work, don’t work, and why.
Product managers can also come from engineering, especially those who tend to interact with product managers such as architects. Again, the motivation can be rooted in frustration and the sense that “I can do this job better”. Or, the realization that coding products isn’t a long-term career goal.
I have also seen great product managers come from quality assurance. The attention to detail that QA instills helps condition product managers to “sweat the details” of a great user experience.
Every path into product management – pre-sales, engineering, customer care, quality assurance – brings a valuable facet to the product manager job. And experiences that product managers per se wouldn’t otherwise have to the same depth.
Which leads to my final point. No matter what your heritage, you are only bringing one facet of the role based on past experience. Thus, product management is a journey of curiosity, learning, collaboration, trial & error, persistence, passion and so forth. Product managers who demonstrate those traits tend to succeed. And the rest probably less so.
“Why can’t we build cool products like Apple?”
If I hear this question in a high tech company again, I’m going to puke. For starters, because your/my company doesn’t have Steve Jobs. He’s a freak of nature. A genius of sorts. And one of a tiny number of people in the history of the technology industry that have his skills.
But lots of companies make great products and lots of money without needing a Steve Jobs. Shouldn’t we focus on that instead?
First, let’s stop doing the things that are sure to deliver a bad product. That should raise the chances of success by 50%. Such as: catering to a small percentage of a user base with esoteric features that will appear complicated to the rest. Or, rushing to deliver something without proving it’s useful and useable.
Then, let’s do the things that look like best practice. Spend the time upfront designing it right. Explore contrarian approaches and avoid mimicking competitors without knowing exactly why.
Sweating the details. Avoid making the user’s life too complicated with extraneous features. Wait a minute, isn’t this what Apple does so well? 😉
Can we please stop calling it “software engineering”?
I’m a deep skeptic of “absolutism”. And the use of “engineering” to describe software development breeds absolutism.
The word Engineering in other contexts is grounded in science. As if there is one answer, or at least one best answer, to a scientific problem. For example, mechanical engineering is bound by properties of the materials in use.
Whereas software development is about the art, not science, of using languages. While languages have rules, they also have flexibility. Use of a language can be precise, obtuse and everything in between.
Lots of priorities can be served (or not) with a given program. Want your code to be performant? Want your code to be maintainable, as in understandable by others? Want your code to be modular so that it can be easily refactored or replaced? All will affect how the code is written.
If you doubt the flexibility of coding languages, then what can explain software quality assurance? After all, these myriads of tests are to deal with the innate diversity, flexibility and expressiveness of code and of the coder.
And we haven’t even got to the choices in designing components of code and architectures.
So why does this matter? Because thinking about software development in – pardon the word – binary terms ignores many of the choices and challenges of building great software products. You might not care about things like “cyclomatic complexity”, but you will when you inherit someone else’s code from 10 years ago and you need to keep it going.
We need to focus on choices not absolutes; on degrees of truths. Software has gotten too damned complicated to think of it in simplistic terms.
Maybe we should call developers “software linguists”?
What makes a great product manager?
This topic has been covered by many, many bloggers. Yet most have written from locales such as the U.S., where things are different from my current home.
I’ve been thinking a lot about the challenge of building a great product management team here in the Czech Republic. Particularly given the relative dearth of software vendors, which means that experienced product managers are in scarce supply.
Experience is a tempting credential to rely on when hiring. Product management, to paraphrase my esteemed colleague Alan Lefort, is more like a trade guild than a university-taught profession (despite the lively debate over on Cranky Product Manager a few weeks ago).
First, I started thinking about good product managers I’ve known in the past, from places such as San Francisco or Boston. What was in common beyond the obvious experience they had in software product management?
I also thought about the less-than-great product managers I’ve known, and even hired. All had the requisite experience, but somehow that wasn’t enough.
So if it isn’t experience per se, nor a formal degree, what is it?
Intellectual curiosity.
Without exception, great product managers are great learners. Their innate curiosity means they are always in a mode of learning. It could be reading a book, or asking great questions of others in their own company, or networking with experts, etc.
I’ve recently toyed with intellectual curiosity as a primary interviewing topic. You would be amazed at the disparity of answers from otherwise qualified candidates. Some couldn’t cite any example of how they pursued their curiousity to better their work. Others gave tremendous answers.
The most memorable example of late: a user experience designer told me he learned anatomy in order to better understand how people interact with computer interfaces. And that he studied corporate finance in order to better measure the impact of usability improvements on his product’s financial performance. Wow.
(Note from the cynic in me to future applicants: don’t confuse knowing my hiring criteria with meeting them.)
One of the greatest effects of the Internet is the extreme democratization of knowledge. There’s no reason to not be curious; so much knowledge is free. Those product managers who are curious will be richly rewarded. Those who aren’t are going to be left behind.
San Francisco days and the “failure stigma”
I just wrapped up a week-long trip to Silicon Valley. Despite traveling here probably 70 times or more over the years, I always feel the special energy of the place. And it energizes me in turn.
Lots has been written about Silicon Valley’s culture of innovation and the appreciation of good ideas and smart people. But what distinguishes this place the most, in my opinion, is the acceptance of failure.
Failure is the inevitable by-product of innovation. After all, most innovation fails to live up to its commercial promise. But nowhere else in the world is there a systemic lack of the “failure stigma”. And somehow this unleashes a form of creativity that is less constrained by concerns about eventual success or failure.
An example: have you ever been in a brainstorming meeting with colleagues? Where you came out of the meeting with some really good ideas? Did you notice that few if any of those ideas were implemented? Maybe it’s the “failure stigma” that stood in the way.
I think managers and executives are the source of the stigma. And those who punish failure and reward success in binary terms are losing the subtleties of two things. First, why was a success a success? We often don’t actually know. So how do we know how to replicate success?
Second, what can be learned from the failures to apply to the future? It’s not “don’t screw up again”. Though these are the signals we tend to send.
So, should the rest of us turn into wanton risk-takers? Not exactly, given the cultures of the many other places in which we live. But a good start would be to create a culture that inspects past failures and seeks to learn. Without punishment.
F**k the competition
In my Product Management profession, there are times when I don’t care what the competition is doing.
There, I said it.
Have you ever encountered The Hysterical Salesperson? Sending me every press release of every $5m never-to-be-profitable competitor is NOT competitive intelligence from the battlefield. I suppose this post is my response to those unnamed colleagues of past, present & future.
Features don’t matter.
If your emphasis is on the feature list of your competitor’s product, you probably don’t gain much. Even for those competitors’ products you can get your hands on, are you really gaining an understanding of the product architecture? Yet it’s the architecture and not the features that will define the contents of your competitor’s future releases. Trust me, I’ve never been so constrained in delivering new features as when an architecture held me back. And your competitors are no different.
Inertia is your friend.
Whatever your competitor’s position, it probably isn’t going to change.
Small companies only have enough money to see their v1.0 vision come to fruition. If they don’t get it right (and most don’t), they’re probably screwed. This is their inertia.
A footnote: I was with a company that did a re-start and defied the odds, outlasting 20+ other vendors along the way. Rewarding, yes. Likely, no.
Large companies suffer from inertia too. It’s the resistance to change and the “curse of being big”. If they manage to make a big change, it’s probably on the basis of a major acquisition for which it will take them 12-24 months to figure out what the new, combined company really means.
Competitive analysis or Win/Loss analysis?
To get a sense of the pablum that passes for competitive intelligence, look no further than the epic anti-trust battle when Oracle tried to acquire PeopleSoft. The data that was posted on the Department of Justice’s website was a never-before peek into the inner workings of the high tech industry. Witness one particular example here; those “insights” would be rendered obsolete with either vendor’s next release.
Win/loss analysis, on the other hand, gives insight into the customer’s buying criteria. If your competitor’s product has features that a customer wants to buy, then it’s the customer insights that led you to this fact.
“Me too” = “too late”.
Yes, you might need to follow your competitors’ moves in order to satisfy customer needs. But if you do, you are by definition not differentiated. And therefore you’re not going to make a lot of money being second (or third) into the market with the same thing.
Differentiation does not mean that you have every feature a competitor has, PLUS some more. It means you have a means to serve that customer in a better way. Or perhaps you have a slightly different customer in mind.
Which leads me to my next point.
What really matters (sometimes it’s features).
Your customers matter. You are in a race to understand them better than any competitor. In that regard, win/loss analysis is invaluable, because it’s focused on the needs of the customer and who’s serving them better. But there are so many other things to be done to arrive at true understanding of your customer.
You’re also in a race to drive change better and faster that your competitors. Remember competitor inertia? It’s only a friend if you can drive change in your company. The change I’m referring to is applying that customer understanding to your product roadmap, your positioning & messaging, your mergers & acquisitions strategy…..pretty much everything the company does.
Influencers matter: perception is reality
Analysts, product reviewers and other types of influencers matter. But let’s be clear about their influence.
Some will set functional criteria, especially product reviewers. These deserve your attention if your customers use these reviews. But be honest about the reviews that matter and those that are noise.
Lots of analysts don’t dwell in a world of features. My good friend Paul Stamp was an analyst at Forrester Research. His customers’ inquiries about vendors didn’t focus much on their features. Rather, customers were looking for vendor “fit”. Did this vendor serve customers like me?
P.S. to Paul: more bloggery please.
End: /(rant)/
Ask yourself: are my user personas in order? Does the company know and love them? How am I measuring user experience? User satisfaction? Influencers’ temperature?
You’d think I don’t pay attention to competitors. You’d be wrong. I spend enough time on competitors to get a sense of who they are. What their DNA is. This will explain 80% of what their future holds. And getting a higher-fidelity read on them requires a lot of time & money and the appetite to sustain that effort over long periods of time. Most of us just don’t have the will.
I respect competitors, but I don’t fear them. They have their own warts.
On Product Management: influence, authority and accountability
The Cranky Product Manager did me a wicked huge favor (that’s “Boston-speak”) recently. In turn, I spent some time on her blog and was reminded why I visit so often.
I got to reflecting on the the mission of product management. Given it’s such a wide role, and manifests in a variety of flavors across companies, I couldn’t come up with a single “model” for how it should work. But I searched for some commonalities.
Three words that get tossed around when product managers commiserate in a bar (or online) are influence, authority and accountability. Influence is often discussed as something that’s mutually exclusive to authority. And product managers often yearn for more authority. Accountability is often discussed as in “how can I be accountable without authority?”
So do I need authority in order to be effective at product management?
Authority. I don’t have much, if any. Nor does my boss, if s/he works for the CEO. Nor does the CEO, if you have a board of directors. Nor does the board if you have venture investors or stockholders. You get the picture. We ALL have a boss who’s somehow more in charge of the product than us.
So what.
Which got me thinking about influence. Those with great influence tend to have tremendous power to shape & shift a company’s behavior. Sometimes, strong influencers are seen as having authority. I think this is the desired state for product managers.
Which leads to accountability. What am I accountable for if I have no authority?
I’ve heard CEO’s, venture investors and board members say “I want my product managers to act like they are the CEO’s of their product”. If you’re a products company, isn’t the CEO the CEO of the product?
One is accountable, in my mind, for the quality of investment decisions and the quality of their implementation. Decisions meaning the trade-offs between competing investment priorities that yield maximum financial results. And our job is to facilitate this process. Really well.
How? Know your market. Know your buyers. Know their pain points. Know what solutions they will pay for.
Quality of implementation means knowing how to describe the solutions in accurate and compelling terms to those who will build & deliver them for you.
A final thought. As I’ve advanced in my career I find myself spending less time worrying about authority and more about influence. Ironically, with every passing year I gain more authority. Sure, the cynic in you might be thinking I’m just being smug. I don’t agree. I invest more time building bridges with peer functions and trying as best I can to ensure that, as a group, we make investment decisions based on sound preparation. And then implement them like crazy. That’s what I feel accountable for.
Don MacLennan | High Tech Yankee 