Friday, August 27, 2010

When price isn't enough: Experiment

When your customers behave as though your products are commodities and focusing on price only, what should you do? No one want their products to become commodities. We strive for differentiation in both brand and features. Then we expect the customer to pay a premium and become loyal to our superior products.
Well, unfortunately customers are more lazy than that. They see switching costs as more important than premium. Low expectations on products actual and usable features combined with routinized behavior is commonplace. Researchers call this a psychological state of mind that drives commoditization. It is no longer the actual features, or lack thereof, it is the mental map of the customer that drives their behavior.

What should we then do to circumvent this behavior? Experiment on price! Use differentiation of price as one way of getting your customers to notice the difference in offerings. You don't know what your customers prefer and how you actually compare to the competition. Instead of guessing, experiment with pricing and products.

In several different experiments (one referred to in Dan Ariely's excellent book Predictably Irrational) customers get two similar products with different price (the more expensive has some additional features). Roughly 60% goes for the cheapest and 40% for the more expensive one. Adding a third product priced well above the previous expensive product shows interesting customer behavior. Now 10% goes for the new most expensive, 60% goes for the middle (previous most expensive) and 30% for the cheapest. By having an expensive alternative to compare against customers tend to go for the middle priced product. Viola, we have moved 30% of customers upwards just by introducing a product we don't want them to buy - just compare against.

Could we know this ahead of the experiment? No, just guess. A simple experiment helped us gain more knowledge. Will it work for you? Don't know, try it out in a smaller test market or segment.

Here's some more strategies to try out to circumvent commoditization:

  • Use price structure to clarify your advantage
    • As you could see in the example above, a pricing structure forced your customers to closer investigate the features of each individual alternative in the structure.This is taken to the extreme in Chris Anderson's Free where one model is called Freemium which starts at the price of 0 and goes upwards.
  • Willfully overprice to stimulate curiosity
    • When customers are faced with a product priced higher than their mental expectation they actually do investigate it further. What additional features does this have that I may have overlooked before? Beware that you better have some valuable features, otherwise they will dismiss you without further consideration in the future.
  • Partition prices to highlight overlooked benefits
    • Break bundles into their components and itemize the bill. That forces customers to investigate what they are paying for and start valuing what they are buying. Beware that this can only be done on products and services that they potentially value.Don't list the price of screws in your package.
  • Equalize price points to crystallize personal relevance
    • With many alternatives targeted towards different tastes, use same price to force the customer to see what they value rather than price. Then we get the customer to put focus on something else than price when comparing.

Experiment to see which of these strategies work for you and what the actual price should be. And gone are the days of commoditization in the eyes of the customer.

More to read:

Tuesday, August 24, 2010

RUSH-data enabled through Enterprise Architecture

In a turbulent market an agile organization requires RUSH-data. RUSH-data stands for Realtime, Unfiltered, Shared and Holistic data. An organization with access to RUSH-data has the building blocks to become agile and act upon market changes with unprecedented speed. It does not, however, guarantee that it moves faster and more vigorously than others.

  • How do you enable RUSH-data? 
  • Which parameters to tune? 
  • How can Enterprise Architecture help setting the level for where to extract the data and when? 
First an example to get the thoughts flowing. Zara, the Spanish fast-fashion retailer, co-locate staff from design, manufacturing, supply-chain and store operations in units of 240 people per cohort. That enables the people to share unfiltered data in realtime enabling them to get an holistic view of the current state. That enables them to respond much quicker to market demand and get new designs in stores within 3 weeks instead of 3 months for competitors. The cumulative effect over the years has led Zara to outpace their competition in growth and profitability.

Where does Enterprise Architecture come into play? Isn't this a case for not using Enterprise Architecture and trust oral word-of-mouth instead of complicated ERP systems? Well, it could be if you don't succeed. But we've done communication for thousands of years and still only Zara manages to leverage human communications. So how can Enterprise Architecture help here?

First of all you must have a culture of information sharing and thirst for more data. Otherwise no system in the world can save you. Prepare for a funeral ...
Then I believe Enterprise Architecture can help in these ways for each element of RUSH-data:
  • Realtime
    • EA sets the non-functional requirements for gathering data. Is it set for real-time or only providing snapshots? How does the snapshots accumulate across IT systems? Will it distort data accuracy and age?
    • Which data needs to be available in real-time to enable RUSH-data?Aggregation of data across systems often leads to distortion disabling real-time attributes. When designing the EA design for RUSH-data.
  • Unfiltered
    • Is data available from its sources or only aggregated in reports with conclusions drawn? Can anomalies be traced or is it averaged and crunched to nonrecognition? Trends are important - however trends indicate strong movements. Developments grow from small significant anomalies that needs to be traced and identified. 
  • Shared
    • Collaboration and sharing of information is crucial in todays turbulent markets. A large component is to have a culture of sharing. Assuming a sharing culture, then how can EA drive sharing? Through assigning roles and ownership of data it will be much easier to decide upon how and to whom information should be available and in which format. Through an SOA information can be both unfiltered and shared in the right format to each person.
  • Holistic
    • EA is very good at identifying information ownership throughout an organization. Which master data combined with realtime information from the source will give a holistic view of how we're doing right now? Work on reducing the information size to craft the data-set needed to get the holistic view. Then create services that supply that information in a dynamic manner. Through the SOA the information can be shared, unfiltered access to raw data in realtime. RUSH-data made real through Enterprise Artchitecture.
Next thing to do is how to visualize RUSH-data. What's your opinion on the best ways to make visualization simple, fast and collaborative?

More reading:

Sunday, August 22, 2010

Enterprise Architecture creating the engine for network-based business models


In a world where the network-based organizations are creating the new business models, Enterprise Architecture play the key role in making it all happen.
Value chains represent all activities performed to create the value experienced by a customer. Michael Porter has described this in his 5 Forces where the relative strength of each participant is reflected in the amount of profit they can extract from the value chain.
The business model is the engine in a firm's network-based strategy in how to cooperate with others to create value. The business model therefore plays a crucial role in determining how much profit a single firm can extract from the value chain.
In a value chain there are four sources of value creation; Novelty, Lock-In, Complementaries, and Efficiency.

Two questions that struck me are:

  • How can a single firm control and steer its business model in a network-based value chain? 
  • How can Enterprise Architecture enable the business model to become the engine through leveraging the four sources of value creation?
I think the answer to both questions can be found in using Enterprise Architecture, EA, to guide and steer successful execution enabling the four sources of value creation. Most transactions and interactions, if not most of the value, are created through IT systems. Enterprise Architecture will enable an organization to identify the most crucial parts of its IT system that creates the four sources of value creation. Once identified the organization can through Enterprise Architecture focus its effort on each of the four sources:
  • Efficiency
    • Integration with other partners done quickly and with no effort. Finding the best suited product with low search costs. Reliable lead-times and costs.
    • EA focuses on the business processes and information exchanged. Thus it is possible to remove bottlenecks and based on which levels of efficiency creates the most value put the efforts there.
  • Complementaries
    • Flexibility in terms of vertical and horizontal integration. Offer additional services and products that complement the product. 
    • EA will based on which types of vertical integration is available enable fast and smooth integration. Information necessary to provide data about available complementaries, especially those that change over time, is identified through EA.
  • Lock-in
    • Raising the switching costs through efficient loyalty activities. Recognizing me as a customer. Not just discounts but more importantly access to improved information, priority, customization, etc.
    • EA identifies which information and business processes that drive the most customer loyalty. Providing that information through the different processes and through the value chain enables larger shares of profit to be extracted.
  • Novelty
    • Enable flexibility in terms of transaction structure, transaction content, offerings through network of partners and complementaries.
    • EA does not only focus on the current state of affairs, but more importantly where the organization is heading. Areas where Novelty are important will be identified and necessary information, business process and IT system support is created.
I think you should ask yourself: What is you position within the value chain? How are we utilizing the four sources of value creation within our current business model? Which IT system support is needed?

Further reading:
  • The Network Challenge: Strategy, Profit and Risk in an Interlinked World by Paul R. Kleindorfer
  • TOGAF 9 A Pocket Guide by Andrew Josey

Friday, August 13, 2010

Designing experiments for succeeding or failing in a turbulent world


How to design experiments that surface flaws in your mental maps about what the future holds? Succeeding in turbulent times requires the commitment to action while knowing that your map of the future is flawed. Running experiments is the single most important activity singling out what will work and what doesn't. Based on the knowledge gained through the experiments and your increased understanding you can redesign your mental map and increase the likelihood of succeeding.

There are two domains we need to understand better to succeed. That is to identify deal killers and knowing what we are betting on.

  • Identifying deal killers. Which events will kill your idea or business?
  • Knowing what we are betting on. Which unique things are we dependent on to succeed? What will drive customers to our offering? Not the inverse from deal killers.
Getting the cold reality of flawed mental maps enables us to spot weaknesses and opportunities we didn't know beforehand. Experiments lets us under control and with limited bets get a better picture of how our mental map of the future actually fits with reality. Here are five ways of running experiments:
  • Partial experiment. Test one attribute at a time. Test parts of a deal killer or bet.
  • Design holistic experiments. Test multiple variables and the interactions between them on a small scale. Could also be a test launch before a larger roll-out.
  • Explicitly consider trade-offs. Cheap Fast or Certain. But not all three at the same time. Limited budget? Go for cheap on the expense of certainty. Need it fast? Put in more money to match the speed and certainty needed.
  • Stage your experiments. Start small and try out the major killers or bets early. Once decided - go all in for that variable and execute the experiment. In between experiments there are room for discussions - during execution it is focus on results. After each experiment evaluate and decide on next step based on results. Don't hesitate to change your mental map - after all that's what the experiment is all about. Validating and finding more/better facts for the mental map of the future.
  • Avoid experiment creep. Stick to what you decided during an experiment. Don't let findings during the experiment let you deviate from the set experimentation plan.If the results are not as expected - don't interpret them in the most positive way. Change the mental map instead.
How are you running your experiments and what value do you get out of them to clear the fog of the future?

More to read:

Tuesday, August 10, 2010

Has Enterprise Architecture reached its Plateau of Productivity?

Enterprise Architects pride themselves with driving IT from a business perspective. Are they doing that or is it just another case of technology driven IT? This time with structure and control as underlying forces.

What shall Enterprise Architects do to really benefit their organization and add value?
There are two main drivers that you as a business leader have to balance between; Exploitation and Innovation.

  • Exploitation. Exploit any given opportunity to the maximum. Be as efficient and operate with low cost. The IT delivery itself should of course be Lean. But more importantly it should enable other departments to be lean in their processes and operations. Embrace possibilities. Don't be too reliant on standards, especially IT standards. Let each business area decide what is best for them in terms of functionality, not in which system to use. 
  • Innovation. Innovate within the IT delivery. How can we help the business being more efficient? Have IT drive Innovation, from idea generation to replication of new products, services and business models across geographies. Enable exploitation of new innovations through effective and efficient IT solutions. What should they look like? Well, be close to the business and listen, invest in agile IT support systems that are evolving over time. Calculate at least 25% of IT costs to be spent on new development, not just IT operations and roll-out.
The aim for an Enterprise Architect is to enable, guide and steer the IT delivery between these two extremes. Pushing Exploitation to be as efficient and extract as much profits out of any given opportunity. Driving Innovation to create new opportunities and being agile enabling new sources of revenue.

The most important things to get right are then:
  • Interfaces. Let interfaces drive the enterprise integration, not standard systems. Service Bus is a technological solution to a business problem. Get the business solution right then the technology will solve itself. Having interfaces, common data models and master data drive integration will definitely drive integration across business domains in large enterprises.
  • Collaboration. Share ideas, solutions and experiences across all silos. Collaborate physically and digitally. Use video, IM, YouTube, Twitter, etc to share and discuss across the entire enterprise. "If Xerox knew what Xerox knows" is a famous quotation from an organization inventing everything but not exploiting anything to their benefit.
Plateau of Productivity? Yes, unless we focus on interfaces and collaboration instead of steering and controlling Enterprise Architects have definitely reached the Plateau of Productivity. What do you think are the constraints for enterprises making more usage of Enterprise Architects to avoid the Success Trap of staying in the Exploitation domain and getting stuck?

Friday, August 06, 2010

Organizational rust and cholesterol

Organizational rust and cholesterol develops in every successful organization over time. In the book "In search for excellence" Peters and Waterman identified the 43 most successful companies in the US in 1980. Out of those 48 companies that were outperforming all other US companies only three would make the list today. What happened to the others?

It's an easy question to ask and much harder to answer. The background issues can quite easily be identified, the cure is much harder to prescribe.
A successful organization develops over time one or more of the following:

  • Misuse of resources. The once successful departments get the majority of resources out of old habits.
  • Misaligned strategy. What was once a great strategy and market position is today just stubborn actions.
  • Leadership dissonance. Blame and backstabbing is spreading throughout the leadership team on different levels.
  • Organizational immobility. Misalignment and inability within the different organizational units to move forward. It's one step here and one step there but never synchronized and at the right time.
How can this situation be fixed or even avoided?

In a recent HBR article on the theme "Change for Change's Sake" the authors argument that organizations should practice small and larger regular changes to practice the change organizational muscle. They propose a questionnaire that can easily help identify when it is time to initiate a small or larger change in order to avoid rust and cholesterol. 
An interesting thought is to measure the number of ongoing changes in an organization. How well are we at actually change? Do we have an ongoing readiness for change? What different types of changes do we have ready to apply if and when we need them?

What level of rust do you have in your organization and which changes of different size can you make use of?