NPS ® for product managers: a 4-step guide

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

A proud day: shipping a net-new product that just works

bullseyeMy 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.