Brands deals with human needs and wants. Leo Burnett, the advertising executive, said: "The work of an advertising agency is warmly and immediately human. It deals with human needs, wants, dreams, and hopes." Smart brands know not to initially focus on what they have to sell but rather on how it meets consumers' needs. If you can address a strong consumer need, you will get those consumers to act. If you can get them to act, then you have opened an all-important channel of dialogue.
The fulfillment of consumer needs, however, is not always a linear hierarchic approach as proposed by Maslow and effectively debunked by Forrester analyst James McQuivey in his book Digital Disruption. Human needs take place simultaneously and are fuelled by a mix of short- and long-term motivations — some conscious and some unconscious. As a student, I would sometimes forgo food on a Friday so I could afford to go to a concert that night; or consider a Spanish couple postponing the short-term comfort of a much-needed upgrade to their central heating so they can put their child through the next year of college.
The pyramid diagram below shows how the foundation of this needs-based thinking is built from the ground up, from customer descriptions through to the technology and KPIs applied.
Within the modern applications era, regardless of whether new software applications are being developed and delivered for mobile, tablets, or the Web, the truly successful app-dev leaders will be those who focus on delivering constant value and incremental improvement to their business. That is a totally different perspective from “I need to keep control of my team’s productivity to make sure that we stick to our estimated costs, scope, and project dates.” Of course, the interest in cost is never going away, but app-dev leaders today have a great chance to enhance their conversation with executives and business stakeholders and add value to the conversation.
However, as the recent research I just published, Agile Metrics That Matter, proves, while some of the most advanced Agile teams do use new progress, quality, efficiency, and value/benefits metrics (these to a lesser degree), some software development industry luminaries have worked and are working on new methods to measure value in software development. But it’s still early days!
I’d like to summarize here some good old practices on establishing metrics that count together with some of the new findings of the research:
I help hundreds of technology buyers each year to understand the impact of technology changes on their software contracts, but I also get questions from software providers about how best to price their products. Some are bringing new products to market and want to know how to maximize revenue, while others are struggling with obsolete metrics such as per processor and want to update their pricing for the modern mobile, cloudy world. The answer is usually to find licensing metrics that make their pricing value-based while balancing simplicity and fairness. The more value a customer gets from your product, the more they should be willing to pay for it. If you make your pricing too simple then you won't match value sufficiently closely, which will cause you to price yourself out of some deals and leave money on the table in others. If, OTOH, you try to match value too precisely you risk making your pricing so complicated that buyers will reject it, and you, completely.
For example, suppose you have a product that will help people do their jobs better, so you decide that charging for each user will be a good approximation for value. The potential problem is that not everyone will use your product the same, in terms of depth of functionality and/ or frequency of access. Your single per user price will be unfair to companies with long tails of light, infrequent users, for whom you'll therefore be too expensive. Conversely your pricing will be unfair to you when the customer is mostly power users. To make your pricing fairer you could have different prices for different categories of user, but then you risk being criticized for being too complex.
I just wrote a paper on the value of information security. Please see the paper here. It is something I have thought about for a long time. Information security as a technical discipline but someone has to pay for all this fun we are having. My assumption is that as Willie Sutton is quoted as saying "Go where the money is...and go there often.” Today where organized crime and nation states are going is to information. It is amazingly easy to monetize certain kinds of information. There is a buyer for everything that hackers can steal. The impact to business has been debated for some time and we go to great lengths to perform risk assessments. What we don't do such a good job of is monetizing that risk.
Consider this. If we can monetize the information asset, we should be able to monetize the risk to that asset. The key to monetizing risk is knowing the value of the asset at risk. Different systems for risk assessment have been in place for some time. They all seem to revolve around professional judgment. My argument is that using a combination of threat modeling (war planning) plus simple asset monetization will allow us to monetize risk. The results will not be perfect, but they should be directionally correct. As Doug Hubbard says it is better to be directionally correct than specifically wrong.
There is no doubt that Agile growth in the market is significant, and the growing daily number of inquiries I’ve been getting on Agile from end user organizations in 2012 gives me the impression that many are moving from tactical to strategic adoption. Why’s that? Many reasons, and you can read about them in our focused research on Agile transformation on the Forrester website. But I’d like to summarize the top five reasons from my recent research “Determine The Business And IT Impact Of Agile Development” :
Quality was the top — quite astonishing, but both the survey we ran across 205 Agile “professional adopters” and the interviews across some 21 organizations confirmed this. My read is that this is about functional quality.
Change was second to quality. We live in an era where innovation strives and organizations are continuously developing new apps and projects. But your business does not necessarily know what it needs or wants upfront. The business really appreciates the due-course changes that Agile development allows, as they enable the business to experiment and try out various options so it can become more confident about what is really right for the organization. Cutting edge cutting edge systems-of-engagement (Mobile, Web-facing, Social-media, etc) require lots of Change in due course.
I’m a sucker for good, biting humor, and in the spirit of Stephen Colbert’s Medals of Fear that he gave to a few distinguished souls (the press, Mark Zuckerberg, Anderson Cooper) at the rally in Washington D.C., I would like to hand a medal to the U.S. State Department for its 1999 publication of a country-by-country set of "Y2K" warnings — “End of Days” scenarios and solutions — for Americans doing business in 194 nations. I would give another medal to IPv6, the most drawn-out killer technology to date — and one that has had the longest run at trying to scare everyone about the end of IPv4. At Forrester, we are starting to see the adoption freighter slowly turning via the number of inquiries rolling in; governments accelerating their adoption with new mandates; vendors including IPv6 in their solutions; and the Number Resource Organization escalating its announcements about the depletion of IPv4 addresses (only 5% left!). To add to the drama, vendors are in the process of creating IPv4 address countdown clocks to generate buzz and differentiation. These scare tactics haven’t worked because technology pundits haven’t spoken about IPv6 in business terms. There is enormous business value in IPv6; those who embrace it will be the new leaders in their space.