The Best Feature May Be The One You Don’t Build
A lot of my recent research – about SaaS/PaaS, Agile tools, requirements tools, and innovating with your channel – share a common conclusion: successful technology vendors see integration as more than just a necessary evil. Here's why.
Business problems drive technology adoption
You can see this principle in action in the requirements tools market, which in the last decade has grown larger and more complex. Teams use these tools to address more than one type of requirements-related challenge, so it's easy to see why the tools themselves are now as diverse as as Micro Focus (née Borland) Calibre, Atlassian JIRA, Ravenflow RAVEN, and VersionOne's Ideas Management module. If your problem is, "People don't like using our product," you might look at a visualization tool like iRise to shorten the feedback loop, leading to better design decisions. If, instead, your problem is, "We don't have a good business justification for what we build," you might look at IBM Rational DOORS to evaluate the pros and cons of alternative scenarios for what goes into the next release.
Business problems manifest themselves differently in each organization
Our recent research into Agile adoption and Agile tools discovered that teams start the Agile journey for a variety of motives, follow different paths, and arrive at diverse outcomes. There are lots of reasons for this Agile heterodoxy, but they ultimately boil down to a basic principle: if you're going to transform the fundamentals of how an organization gets work done, you're going to get deep into the politics of that organization. As Daniel Patrick Moynihan famously observed, "All politics is local."
Business problems are not compact
Rarely do business problems neatly limit themselves to a single department. The statement, "People don't like using our product," might be shorthand for, "We don't listen very well to the customer-facing groups, such as Sales and Support, who are telling us what customers think of our product." Or, that statement might mean, "We don't do a good job of translating features and functions into marketing and sales messages." In both scenarios, the problem spans more than just the development team. Consequently, the solution may depend on tools that these other groups use. Want to know how important it is to match a competitor's feature? Win/loss data in the CRM system will tell you how much of a threat that competitor is, and maybe even if that competitor's feature set is the reason why companies choose them over you. Need to make sales training more efficient? You may need to post updates about an upcoming release on sales team's internal Wiki.
From the customer's perspective, your technology is a cog, not a machine
Technology vendors should stop using the word solution to describe their products and services. The solution is what the customer builds, using a combination of technological and human components. For example, Sarbanes-Oxley demands that corporations follow strict financial controls, and then provide proof that they're living up to these standards. While there might be tools that help with the reporting requirements, technology may not be able to help as much with changes in daily accounting work. Since auditors make it painfully clear that you can't be compliant without implementing and documenting financial controls, the customer cannot really build a "solution" on just that portion that technology addresses. In this, as well as other cases, no matter how cosmically capable your technology may be, it's never more than a moving part in a larger solution architecture.
Customers don't want to deal with you
According to one of our recent surveys on software purchasing and adoption, 67% of buyers want to deal with channel partners, not the vendor directly. This fact of life reduces the amount of information about how and why people adopt technology from reaching tech vendors. These gaps make a difficult challenge, building technology that will satisfy diverse customers, that much harder. Do European privacy standards have any effect, in practice on how e-mail archiving works? Do case management systems need to integrate with the same e-mail clients in very small and very large companies? Sometimes, the best answer for the vendor is, "We don't know, and we're not likely to know any time soon." To deal with these market-specific requirements, channel partners need to pick up where the channel partner left off.
All of these hard realities point to a fairly obvious conclusion: integration is often a better development investment than features. Business problems are sprawling messes. To deal with them, people must attack them on multiple fronts, using a mix of human and technological measures that will be different in every organization. Vendors see these struggles from a distance, and usually only in flashes. Therefore, the people on the front lines may not want your ill-conceived megaweapon, but something manageable and precise that they can use easily with other tools. Product managers need to give integration its due in inbound activities, such as roadmap priorities. If product marketers aren't sure how to convey the value of integration, they need to put that item on their to-do lists.
[By the way, I'll be talking about the channel research at Forrester's IT Forum in a couple of weeks. There, I'll also be presenting our analysis of the requirements tools market with colleague Mary Gerush, and in a teleconference next week.]