If your engineering team hasn’t already moved to some form of Agile methods (like Scrum or XP), then it’s likely they’re at least considering it. Agile really does attack some key problems that have plagued software teams for decades. But many product managers and designers, and to a lesser extent QA staff, are initially confused by Agile, unsure of their role in these methods. To be clear, these methods absolutely require these roles, but I attribute the confusion to the origin of Agile methods, and I’ve found that when I explain the origins, it helps to illuminate the problems that Agile was designed to solve, and what challenges remain.

Many are surprised to learn that Scrum, the most popular of the Agile methods, is now over 20 years old. It was created in 1986 in Japan. (Yet another example of just how long it can take for a new idea to reach the tipping point).

But most importantly, these methods originated in the custom software world.

The custom software world – building special purpose software for specific customers - has long been a brutally difficult type of software. This is partly because customers notoriously don’t know what they want, but they have a need so they write a contract with a custom software supplier, or sit down with their internal IT folks, who then work to deliver, and when they do, the customer invariably responds that this isn’t really what they had in mind, so the cycle continues and frustration mounts. But the core need still exists, so this has provided job security for countless IT developers, custom software shops, and professional services businesses.

Further, custom software has long been on the short end of the stick when it comes to recruiting and retaining top software talent. Partly this is because many top software professionals prefer to work for companies that are in the business of creating software for thousands if not millions of customers. Partly it’s because software professionals get paid more at product software companies where the product team is responsible for coming up with software products that please many people, or they don’t make money. So these companies know they must hire the talent necessary to create winning products, and they pay accordingly. But to put this in perspective, only a relatively small percentage of software people actually work on commercial product software; most work on custom software.

In the custom software model, since the customer believes he knows what he needs, you’ll rarely find the role of the product manager. Likewise, you’ll almost never find user experience designers. The reasons for this are more complex, and involve a degree of ignorance (relatively few in the custom software world realize what user experience designers do and why they’re needed), and cost-sensitivity (cut costs by letting the developers design), but to be fair, due to the shortage of designers in our industry, the few that are available are immediately grabbed by the product companies that realize how critical they are, and so custom software teams can rarely find designers even if they have the leadership that realizes they need them. Similarly, QA as a discipline is rarely found in custom software projects; again, the developers are typically expected to do the required testing.

Another crucial element in understanding the custom software world is that the vast majority of custom software projects are relatively small and done to support the internal operations of a company – applications like HR, billing, and manufacturing, where the limited number of users means that issues such as scalability and performance are usually less critical.

Historically the custom software world used the Waterfall process because the various stakeholders needed a way to monitor progress during the long process of creating these contract applications. In fact, the Waterfall methods originated here as well.

In the product software world, where the software must sell on its merits, we introduced the roles of product managers to gather and represent the needs of a wide range of customers; designers to create usable and desirable user experiences; and QA testers to ensure the software worked as advertised in the range of customer environments.

But in the custom software world, the same fundamental issues of coming up with something that satisfied the customer continued. For these teams especially, the Agile methods represent significant improvements. They improve the communication between the customer and the engineers. They significantly reduce the risk by building smaller, more frequent iterations so that the customer can learn whether he really likes something or not much sooner, rather than wait for the end of a long process. They help introduce some modern software testing concepts, and they help relieve the team from spending countless hours preparing documents that are rarely read and quickly obsolete.

In general, these are great benefits for product software teams as well, but I always explain that a few adjustments are required. I’ve written earlier about these topics, such as how to insert user experience design into the process, and how to manage releases and deployments, but another area that has struggled is the architectural design area.

The Agile methods encourage engineers to not get attached to their implementation believing that things can be re-factored or re-architected relatively quickly and easily. This is true for the vast majority of custom software, but for many product software systems, such as large-scale consumer internet services which must support hundreds of thousands if not millions of users, this approach can be naïve.

So it shouldn’t be a big surprise that the main issues that many product software teams have encountered with Agile methods stem from the custom software origin. The many books, articles, and training classes that don’t mention product managers or any form of user experience designers (interaction designers and visual designers) weren’t meant for product software teams.

My suggestion to teams moving to Agile is to make sure the firm you hire to help your organization actually understands the differences that product software demands. Most don’t, but enough do.

Email to a friend

Sign up for the free newsletter here.

Very often I’m asked how product managers should be measured. I have long believed that the only true measure of the product manager is the success of his or her product. While I still believe that, it’s not a very satisfying answer, as it’s not clear what the best way to measure a product’s success is. Is it revenue? Profit? The number of users? Page views? All of these indicators can be useful but they don’t really provide the big picture.

Recently, a business metric has been gaining traction across a number of different industries, called the Net Promoter Score (NPS). You can read all about it if you like at www.netpromoter.com. It’s a very simple metric. You ask your customers how likely they would be to recommend your product, on a scale of 0-10. Those that rate 9 or 10 are considered “promoters” (they’re out there telling their friends how much they love your product, and are actively evangelizing for you); those that rate 7-8 are lukewarm or neutral; and those that rate 0-6, the “detractors,” are not likely to recommend your product, and may even be actively warning their friends about your product. If you take the percentage of promoters and subtract the percentage of detractors, you get the NPS. This essentially tells you if you have more people cheering for you or against you.

Quite a few companies already track this metric, and those that rate very highly won’t surprise you – companies like Apple, Amazon and eBay.

I very much like this metric because it puts the focus on the product and the overall customer experience. If, as we like to say in this business, it’s all about creating happy customers, then this is a measure of exactly that.

Yes, in theory you could have 100% very happy customers but you go out of business due to losing money on every customer, but for a single metric, I believe this keeps the focus of the company on creating happy customers, which is what fuels growth. And in terms of profitability, there is no more cost-effective sales or marketing program than your own customers doing the sales and marketing work for you, so I have long believed that a great product with happy customers lowers these other (often very significant) costs, which contributes to profitability.

This leads to the concept of good revenue and bad revenue. For example, let’s say the company is approached by a big potential sponsorship or advertising partner, that covets your user base and believes they can effectively sell their product on your site. This could be a good thing or a bad thing, depending on how it’s done.

If it’s done poorly, the short-term revenue might be nice, but if it hurts your customer experience, it will be reflected in the NPS, and your business will grow more slowly, or worse. On the other hand, if you can work collaboratively with the advertising partner, if it’s done well, it could be either neutral to the customer experience or even contribute to the experience, which will help your business grow more quickly.

This is why “specials” are so dangerous. They represent bad revenue, and hurt your company’s ability to deliver products that create happy users.

You can compare your NPS across companies and even across industries, which is interesting, but to me this is most useful as a way to measure your own progress towards improving your products and services. So if you don’t already measure your NPS, consider doing so as soon as possible. Then you can start watching how the changes you make to your products impact this score. Make sure you’re always moving in the right direction, and consider the impact on the NPS of everything you do.

Email to a friend

Sign up for the free newsletter here.