Aligning Corporate Strategy and Product Strategy: In the beginning
by David Locke
http://www.noozit.com/author/David+W.+Locke
--------------------------------------------------------
When you start up, you don't have any of the following: money, bills or cost structure, customers or market, product or marketing.
You have an idea. You have hope. You have perseverance. You have some partners. Your corporate strategy and product strategy are aligned.
You get around to the make or buy decision, and lacking money, you have to go with the make strategy. Or maybe you think, "Hey, I'll get some investment money and then I'll make or buy. Or maybe, I'll find a client and let them pay me to develop my technology and productize it in their solution. Or ...." The endless Ors. The money you have is disappearing, so you stop with the Ors, and dive in.
I'd go with the get a client strategy. A former partner went with the "we'll get some VC capital and then build," but the VCs wanted an install base. So my former partner's strategy and the strategy of the VCs involved were not aligned. When the strategies of those involved in anything are not aligned, time passes and nothing happens.
So I get a client. I could tell the client about a solution, but I'm in the technology business, so my job is to listen to my client and align my technology with their needs. In Christensen's terms, I need to enable my client to do a job--his job, not mine. My strategy is to enable my client's visualization. It is both my corporate and my product strategy. They are aligned for now.
They are aligned for now only because I haven't yet captured their requirements.
The requirements elicitation process is not about alignment. Requirements elicitation has problems going back to its origin and some basic beliefs that got embedded in its methods from the earliest days. At its core, requirements elicitation is about programmer efficiency. The rationale was that programmers and computers were expensive, so let's come up with ways to cost-effectively use those resources. So these days I'd have to ask, "Are programmers and computing that expensive? Relative to what?" In an IT department, is it more expensive to code or to use? With the cost improvements brought by software engineering, education, and training, the dot-com bust, offshoring, and open development, code is free, or at least a heck of a lot cheaper than it used to be. So the cost of software has shifted to use.
When the Total Cost of Ownership (TCO) concept was developed by Gartner back in the late 1980s, Gartner circulated a draft definition of the TCO. The definition listed all the cost contributors and categorized them. There were business administration costs like license renewals and such. There were technical administration costs like installing the database. This was back when client-server was new and the Internet had not yet arrived. Even desktop installs that you did yourself were going to involve IT staff in various ways. There were costs for training and technical support. There were costs for the salaries of people as they performed self-support, read manuals, or went through the tutorial running on their machine. These latter costs were called negative use costs. Negative use costs summed up all the time spent on things that could not be considered productive work. They looked like work but didn't move any production towards completion. Gartner couldn't find cost data for negative use costs, so the category was eliminated from the definition of the TCO.
Those omitted costs are still incurred. They embed themselves in the cost structure of the client's and customer's businesses. In some sense, they represent the lack of fitness between the application and its user. They represent the cost of focusing on developer efficiency rather than user efficiency. They show up in features like an export to Access function. Why export to Access? Well, the user has to reorganize the data because it doesn't fit what they are trying to do. Once it is exported to Access, where does it go? It goes into Excel, so the user can manipulate it until it looks like the deliverable they need. The deliverable, you might argue, that should have been generated by the application in the first place.
If you are listening to your customers, ask them where your data goes. You might even have export to Access and Excel features in your product already, but then where does it go after that?
In school, we are taught that requirements pertain to the WHAT, and not the HOW. We are taught that functional requirements pertain to the WHAT, and that non-functional requirements pertain to the HOW WELL. And that was that, unfortunately. At a hypertext conference back in the late 1980s, some MCC researchers presented their work on formal requirements. They were trying to overcome the problems with program proofing. Proofs of programs, back in those days, could prove that the program was consistent in itself, but you could not prove, scoping out, that it was consistent with the system it was a component of, or that it met the requirements. The important take-away is that requirements are decisions.
The latest research on requirements and requirements elicitation that you can find in open sources on the Internet was done back in the early 1990s. In that research, the researchers found that requirements elicitors start with a theory, and they ask requirements questions. Those questions give the customer the opportunity to make decisions. But the elicitor's theory controls what questions are asked. So eliciting requirements is not listening.
The customer is hungry, so they go into a restaurant, they know what they want, but the menu only has three items that get close to what they want. They pick one. Oops. They pick another. In the end, they are not happy. Their product visualization was not met. Their choices were limited. My company strategy depends on the client being happy with the product, because they will evangelize the vertical, or at least their successful business case will be core to the marketing. The business case can't have an unhappy client. I can't have a theory. The technology I'm trying to productize is just a black box to them, not the solution. The product is the solution. That product is theirs, not mine, not ours, as in our company's product.
Requirements change a lot, or so I'm told. We have come to accept requirements volatility as the reality. At the core of requirements volatility is another reason that requirements elicitation is not alignment. Who are we trying to align with? Who do we sell to? And how is the buying process structured similarly to the developer vs. user dichotomy? And how does that create requirements volatility?
We make the first sale to the economic buyer, who on behalf of his employees trusts us to deliver a competitive advantage. The economic buyer may have trained his employees when they arrived, but the longer the employees have worked there the more likely it is that they have trained the economic buyer. The economic buyer might be so far away from the job that they are only looking for a solution, because the user's manager brought the need to his attention. The economic buyer is not the user. The economic buyer is distant from the use, and user. The economic buyer is distant from the meaning as well. The economic buyer also has a larger scope than the user, which makes it likely that the solution will involve many functional units, and the economic buyer becomes the executive sponsor. At the point where you have an executive sponsor, you are no longer explicating requirements from users. You will end up with a politically constructed abstraction that delivers average use. In that average will be enablement and disablement; positive use costs, and negative use costs. Average use is fitness for no one,except the mathematically constructed model of the user. In one sense it is a nice thing, because this mathematically constructed model of the user becomes the root of a mathematically constructed model of the market, as in market segmentation.
All of us have heard the term "corporate culture." For any organization, its corporate culture is the culture of the politically dominant functional organization within that organization. In firms that see themselves as engineering firms, engineers dominate. In firms that see themselves as brand-driven, marketers or sales dominate the firm. Corporate cultures define meaning within an organization. Software is a media that encodes meaning. Requirements elicitation is part of that process of encoding meaning. Going further, meeting a client's, customer's, or market's needs involves encoding meaning--THEIR meaning, not ours.
Given corporate cultures, what meaning is politically preserved by the executive sponsor? Yes, the dominant culture's meaning is preserved and embedded. The dominant culture wins the battles over functionality. Any other culture pays the price in terms of effort and embedded, intrinsic use costs, but they also pay the price of not having their meaning preserved, of not communicating clearly.
The dominant culture is not the only culture in an organization. Each functional unit has its own culture. Each functional unit, depending on how long it has existed, may contain people raised on different paradigms or subcultures within that functional culture. Remember that cultures embed meaning and rituals, rituals like work, rituals like use. They have a vocabulary. They have ways of thinking that differ from outsiders. An elicitor is usually an outsider. Sometimes they get close, but even if they were once or are now one of the functional experts that they are eliciting from, they still may be an outsider.
In cost accounting, there are three approaches. Different universities teach it in different ways with different emphases. So if a functional unit is staffed by people coming out of a particular school, a very likely scenario, they will think alike and have the same priorities embedded in their meanings. If the functional unit is staffed by people from different schools, then the functional unit boss will be the executive sponsor of their meaning and further refinement may be problematic. Still, as the application you build for them ages, that sponsor will change and each user will push their own agendas relative to feature requests. If you don't know who is who, you will insert their internal politics into your product. Once you get to a mass market, you may not be able to deal with this level of resolution, but requirements elicitation strategy is a strategy, one that impacts corporate strategy.
So you might be wondering why I'm bothering with the subcultures in this one client's company. Since this client is paying me to build an application that will eventually be sold into the client's vertical market, that application is a seed of the future. In the late market, or consumer market, or in a recession, mass customization is one strategy you can take to grow. Value-based is another such strategy, one that benefits from finer definitions of value. But even larger is the idea that culture is segmentation, organic segmentation rather than mathematical segmentation. Fitness is higher when the application is aligned with culture.
So what does that have to do with a product manager? Once you escape the reactive situation you found yourself in when you first arrived at your company, you will find yourself being increasingly strategic. It is in your best interest, in the interest of those people who contribute to your efforts, and to your company's interest that you step up to the plate and become strategic. Once you are strategic, you can think about real options, or options to make decisions. If you architect marketing into your product, you have the option of using it later. If your company architects a capability into itself, it does so for its intention to use it later. It aligns itself with its goals. If you build your requirements around culture, those hidden costs go away, the client and customers notice, and when a recession hits, you are ready to keep the growth growing even if it's opaque to your bosses, your market, and your competitors.
The notion of punctuated equilibrium showed that a lot of little changes at the bottom don't get expressed until one more change comes along. Then the entire world changes and somebody in your company looks like a hero. The hero will say something about superior strategy, agileness, or whatever. And no, it won't be your fault. But your future will be golden, because you aligned your product with corporate strategy long before corporate knew it had that strategy.
As for the revenues, cost structure, market, and product, you develop those simultaneously. Keep them aligned.
