A new business model is emerging, and it depends heavily on software development. Many companies are dropping many of the traditional barriers between product development and customers.
Without investing in software development, these efforts, no matter how well-intentioned, will have a better chance of failing than succeeding.
The simplest term I can concoct for this business model is "the transparent company." There are other defining characteristics of this corporate strategy, such as confidence in the ability to execute, and a very different sort of relationship with customers.
However, as companies have been decidedly opaque to their customers, any transparency is a striking detail in itself. Hence the term "transparent company."
Wave hello to the engineer fixing your bug
Here's an example of what I mean. I don't have to be a customer of Atlassian to know what issues Atlassian's engineers will fix in the next release of their wiki product, Confluence.
That information is publicly available at this link. Diving into an issue at random — I chose "Database deadlock during initialisation of plugins in sql server" because it sounded fairly dire — I can see which engineer is working on this issue, Don Willis. I can even see the daily activity stream for Don Willis as he works on this issue and other projects.
Contrast that amount of information (far more than I need, strictly speaking) with how companies like Atlassian operated, say, as close in time as 10 years ago. Instead of putting all cards on the table, these companies kept their cards very close to their chests.
You never knew if an issue like "Database deadlock during initialisation of plugins in sql server" might get cut at the last minute, angering customers waiting for that fix. Or, you might not want your competitors to see that you were struggling with database deadlocks.
If we were talking about a car company, this transparency would be tantamount to putting on the web site that, in 0.05% of test cases, the anti-lock brakes on the next model sedan failed. No matter that the engineers would fix this issue long before the car went into production, auto manufacturers just don't provide that kind of peek into their work in progress.
In many industries, the designer's blog is now de rigeur. Well in advance of shipping anything, companies are willing to talk openly about what they're building, how they're building it, and when it will be available.
Customer insight is like marital therapy: it takes time and investment
So why didn't companies take this approach long ago? The distance between the company and its customers made transparency seem like a wasted effort. Collecting customer intelligence can be a very labour-intensive process, with a great deal of potential miscommunication and misunderstanding.
All the risks (unrepresentative samples, hearing what you want to hear instead of what the customer wants, groupthink, etc., etc.) are very familiar by now, so I won't rehash them here.
Today, the distance between companies and their customers can be a lot shorter, and there are lots of software-based reasons why. For example, a better requirements tool (or any requirements tool) can help make sense of what customers want. And while that sort of tool helps you survey the landscape on the other side of the wall between customer and company, social media lower the wall.
Even the most confirmed skeptic about social media still has to admit that it has changed the conversation with customers, in part because conversations between customers are going to happen anyway. Best to play some role in that discussion than none at all.
Social media are not free. It takes investment to implement Wordpress, Jive, and other packaged solutions for providing social media content, or listening platforms and other applications for leveraging the information about social media activity.
This investment goes beyond flipping the switch on a package application. Everyone does some custom development either within social media solutions, to change their behavior or appearance, or around these applications, to integrate them with other things.
And that same principle applies to other kinds of systems, such as CRM. Here's one obvious reason: Software development is necessary because no packaged application for increasing insight into customers provides 100% of what someone wants.
Here's another, less obvious one: From the start, nobody knows exactly how to increase their insights into customers, so there will be a great number of adjustments to these tools and the way employees use them. If these changes require new customizations, integrations, or brand-new applications built from scratch, software development is required.
These are exciting changes to see happening, but I'm not going to get into a misty-eyed discussion about the co-creation of value with customers. There are plenty of other forums that cover that topic, including some Very Serious Publications. I'm also not going to judge how sincere these co-creation efforts are.
In many cases, "co-creation" doesn't go much deeper than the label that a company applies to itself for corporate marketing reasons. ("We love our customers! We just don't let them affect our product direction.")
Instead, I want to call attention to the very real effort required and the very substantial role that software development plays in that effort. So far, we have only been talking about increasing the transparency of the customer to the company.
This new business model also requires transparency of the company to the customer, in the fashion of the Atlassian example I cited earlier. That sort of transparency requires a lot of confidence in a company's ability to deliver value. Software development plays a different role in creating that confidence, as we'll discuss in the next post in this series.
Posted by Tom Grant