Subscribe To Own As New Lease To Own

The Beatles are timeless and so is music and enterprise software.

There's been an ongoing innovation in the music services. iTunes with iPods disrupted the traditional CD business model and in the ever connected cloud world Pandora, Spotify and countless others are challenging the very concept of "owning" music. Spotify gives you access to a wide range of music on all their clients as long as you're a paid subscriber. This is like Netlfix model for music except that there's no ad-supported free Netflix (Spotify is rumored to cap the free version after six months of usage). Pandora also has a similar model but it's a "radio" service. You can't tell Pandora what exactly to play but give preferences and it will find, play, and tune music based on your preference.

Pandora is serendipitous and Spotify is spontaneous.

One of the challenges with these services is that you only have access to music as long as you pay for it. When you stop using it you don't own anything (from them). iTunes and Amazon, on the other hand, are a music "marketplace". You buy songs and keep them. But these services are not designed for you to explore and experiment endlessly.

I wonder whether there's a middle ground.

What if there's a subscribe to own business model? The services would stream all the music that you want for a fixed price (like Spotify) and users will get a choice of receiving certain number of DRM-free songs — like options being vested, at the end of the subscription plan — say annually. The studios may never agree to this, but it's a great value proposition. What if a service is designed to actually sell MP3s and the streaming is just a draw to get people discover new music? Also, imagine if Netflix were to give out credit to their streaming customers to own a set of movies on DVDs. "Lease to own" is a very popular way of buying a car (at least in the United States). Why not apply that to music?

It is very difficult to change human behavior. The studios are powerful, want full control, and see technology innovation as a threat as opposed to an opportunity. On the other side, consumers are willing to pay and experiment but they do want to own music so that they can play on any device any which way they want without getting locked into a specific service and its supported clients.

What about SaaS subscription models for enterprise software? Are there any issues when customers don't "own" the software that they are using?

I have blogged about SaaS escrow and inverted OEM channels before. We haven't yet seen any spectacular failures of large SaaS companies. Today, even if you're a large unprofitable SaaS vendor with a decent customer base, you will be acquired before you shut your doors for good. But once SaaS becomes the de facto mode of delivering software, the "hotness" will fade away and you are as likely to go out of business as any other ISV. What happens then? The customers have their business continuity plans and a SaaS vendor going out of business could become a serious concern.

As far as music goes, there's a clear separation between content and process. We listen to music which is content and everything else — streaming, matching, discovering, and recommending — is a process to get to the content. This clear separation is not that clear in enterprise software. SaaS escrow could guarantee the content (of course if vendor supports it) but not the process and without process there's not much of business continuity. You could take your music and go some place else but I doubt you can do much with your enterprise data without any process around it. Is there an analogous flavor of lease to own in enterprise SaaS business? I guess, it's too early to say.

Going back to music, I think, we're ready for a radical shift and disruption in existing business models. Lease to own your music may not be a bad idea after all.

Loving What I Do For Living

A few months back, I was helping a very large customer of ours to help simplify as well as automate their process of trading financial instruments. During one of my many visits to their office, I met a person who was trying to explain to me his job in supporting the people that are involved in this super complex process. I always ask a lot of questions — until they're totally annoyed and ready to kick me out of the room — to get a complete understanding of the business rationale behind whatever they're thriving for and their personal motivation behind it. Something unusual happened at this meeting. Instead of getting into the gory technical details of how they get things done, he chose to tell me a short and simple story.

"You know, um.. there's this early morning meeting everyday that Peter goes to with a bunch of other people. They all gather around a large table in a dimly lit conference room with a bunch of printed spreadsheets, a laptop, and a large calculator. Peter has a cup of coffee in one hand and a cigarette in the other hand talking to people who have coffee cups in their one hand and cigarettes in the other hand. This is their lives. I am concerned about Peter and I want him to stop smoking. Can you please help me?"

Now, this is the job that I love that makes me get out the bed and run for it. This is the human side of enterprise software. It's not boring.

Photo Courtesy: Jane Rahman

Design thinking: A New Approach To Fight Complexity And Failure

Photo credit: String Theory by Michael Krigsman

The endless succession of failed projects forces one to question why success is elusive, with an extraordinary number of projects tangling themselves in knots. These projects are like a child’s string game run amok: a large, tangled mess that becomes more convoluted and complex by the minute.

IT projects fail all the time. Business blames IT, IT blames the system integrator (SI), who then blames the software vendor. After all this blaming and shaming, everyone goes back to work on another project without examining the project management methods and processes that caused the failure. And, so, they fail again.

There’s no one definition of design thinking. It’s a mindset and set of values that applies both analytical and creative thinking towards solving a specific problem. Design thinking is about how you think and not what you know; it is about the journey and not the destination.

Having followed Michael Krigsman’s analysis of IT project failures, it became evident that design thinking can play an important role in improving enterprise software development and implementation. 

The design thinking approach offers a means to address the underlying causes of many project failures — poor communication, rigid thinking, propensity toward tunnel vision, and information silos.

I have distilled important lessons from design thinking into six principles that can help stop project failures. Along the way, we will draw comparisons with Agile development, since that distinction is often a source of confusion when discussing design thinking.

These six principles, based on design thinking, can help any project team operate more successfully.

1. Put a multi-disciplinary team in charge

You can’t pin down project failure on one person or one topic and yet we continue to use a person-centric method to manage projects. No one on a project team wants to fail. If you collectively put responsibility of the failure or success on the shoulders of the team and get them trained and motivated to think and behave differently you will mitigate much failure.

Multidisciplinary teams champion the user, business, and technology aspects of a project in a more comprehensive manner than would otherwise be possible. Typically, an IT team talks to business stakeholders who then talk to end users, which creates communication gaps, delays, and inefficiency. Far better to create a single team that includes participants from all areas, creating a single unit that includes multiple perspectives.

Try to staff your project team with “T-shaped” people, who possess a broad understanding and empathy for all the IT functions, but who also have deep expertise in one domain to champion that perspective. This approach can ensure that your solution is economically viable, technologically feasible, and delights the end users. A more balanced team also humanizes the project and its approach. Stay small and resist the temptation to set up very large teams. If you believe the “two-large-pizza-team” rule, those projects are team-driven and tend to be more successful. Start-ups can build something quicker because they are always short on people. As your group get bigger and bigger, other people tell you what to do and team members feel less connected to their work as it relates to the outcome.

2. Prepare for failure in the beginning

I recommend kicking off the project with a “pre-mortem workshop.” Visualize all the things that could go wrong by imagining that the project has failed. This gives the team an opportunity to proactively look at risks and prepare to prevent and mitigate them. I have sat through numerous post-mortem workshops and concluded that the root causes of failures are usually the same: abstract concepts such as lack of communication, unrealistic scope, insufficient training, and so on. If that’s true, why do we repeat the same mistakes, causing failure to remain a common situation? Primarily because many people find it hard to imagine and react to abstractions, but can relate much better when these concepts are contextualized into their own situation.

3. Be both vision- and task-driven

Design thinking emphasizes storytelling, shared vision, and empathy towards all stakeholders involved in a project. On many projects, participants focus exclusively on their own individual tasks, thus becoming disconnected from the big picture.

While design thinking strives to connect participants to the larger vision, Agile development can be very task-driven. Everyone gets a task without necessarily understanding the big picture, or vision, or even seeing the connection between his or her tasks and the final outcome. In this situation, a project can fail and people may not understand their role, thinking they failed due to someone else’s work. If participants don’t realize their tasks contributed to a failure, they won’t try to learn and change.

On the other hand, vision-driven approaches are very powerful. People perform their tasks, but the story and vision persist throughout the project; the same story gets told by different people throughout the lifecycle of the project to avoid that big picture fading away. All the tasks have a bigger purpose beyond their successful execution. Even good project managers miss this point. At review meetings, it is important to evaluate what the team did right but also revisit the vision and examine how recent outcomes fit the overall story.

4. Fail and correct then fail again

Design thinking contradicts other methodologies that focus only on success. In design thinking, failing is not necessarily a bad idea at all; however, we fail early and fail often, and then correct the course. In many projects, people chase success without knowing what it looks like or expecting to fail; therefore, they do not learn from the process.

One of the challenges with traditional project management is the need to pick one alternate and run with it. Turns out that you don’t know everything about that alternative and when it fails, due to the irreversible decision that you made, you can’t go back. Far better to iterate on a number of alternatives as fast as you can before deciding which one will work. This approach requires a different way of thinking and planning your project.

5. Make tangible prototypes

Agile proposed creating unstructured documentation as opposed to making structured requirement documents. But, unfortunately, that is not enough to solve many problems. One of the core characteristics of design thinking is to prototype everything, to make a tangible artifact and learn from it. The explorative process of making prototypes makes people think deeply and ask the right kind of questions. It’s said that “computers will never give a wrong answer but it will respond to a wrong question.” The prototypes encourage people to focus on what I want to know as opposed to what I want to say. This is very important during the initial design phase of the project.

One of the biggest misconceptions about prototypes is that people think they are too complex to make and are overhead or a waste of time. This isn’t true at all. Prototypes can be as simple as a hand-drawn sketch on a paper or as complex as fully functional interactive interface. The fidelity of a prototype is based on what kind of questions you want answered. People tend to fill in gaps when they see something raw or incomplete whereas hi-fidelity prototypes can be too complete to solicit meaningful feedback. As I already mentioned, most people respond better to an artifact as opposed to an abstract document. Prototypes also make the conversation product-centric and not person-centric. They also help to get team members on the same page with a shared vision.

6. Embrace ambiguity

One of the problems with traditional project management methodologies is that they make people spend more time in executing the solution and less time on defining the problem. Design thinking encourages people to stay in the problem space as long as they can. This invariably results in ambiguity, which is actually a good thing.

Ambiguity fosters abductive thinking — a mindset that allows people to explore what is probable with the limited information on their hands without concerns about proving or concluding that it actually works. It helps people define a problem in many different ways, eventually letting them get to the right problem they eventually should focus on.

This also supports the emergent approach that design thinking advocates as opposed to a hypothesis-driven approach. In a hypothesis-driven environment, people tend to focus on proving a premise created by a small group people. Rushing to a solution without defining the problem, and having no emergent framework in place to include the insights gained during later parts of the project, certainly contributes to failure.

ORGANIZATIONAL BARRIERS TO SUCCESS

Even the best methodology requires organizational commitment to success. For design thinking to work, it is also necessary to address these common organizational issues, each of which can impede progress and limit successful outcomes.

Lack of C-level commitment: Although design thinking is applicable at all levels in an organization, executive management must bless it by publicly embracing and practicing design thinking. Top down initiatives and training only go so far.

When the employees see their leaders practice design thinking they are more likely to embrace and practice it themselves. The same is true with adoption of social media and collaborative tools inside an organization. The best signal to your employees is by showing them a firm belief in the method by practicing it firsthand and sharing positive outcome.

Resistance to change: People in any organization are usually fundamentally against change, even if they believe it’s a good thing. They don’t want to get out of their comfort zone and therefore practice the same methods that have resulted in multiple failures in the past. Changing behavior is difficult but fortunately design thinking can help.

One of the ways I have taught design thinking is by taking people away from their primary domain and have them solve a very different kind of problem such as redesigning a ticket vending machine or a fast food restaurant. My team was hugely successful since it was a completely different domain and it didn’t interfere with their preconceived notion of how a project should be executed. People’s reservations are tied to their domain; they are willing to adopt a new method and new way of thinking if you coach them outside of their domain and then encourage to practice it in their comfort zone.

Lack of industry backing: Despite being informal, undocumented, and non-standards-based methodology, Agile experienced widespread adoption. I would attribute this success to two things: a well-defined manifesto by lead industry figures and organizations publicly committing to adopt the methodology. Design thinking lacks these attributes.

Even though industrial design companies such as IDEO has evangelized this approach, there’s still confusion around what design thinking actually means. This also makes it difficult to explain design thinking to a wider audience. If a few organizations publicly endorse design thinking, create a manifesto, and share the best practices to gain momentum, many of the adoption hurdles will go away.

Lack of key performance indicator (KPI) frameworks: Design thinking faces the same challenge that most Enterprise 2.0 tools face: lack of measurable KPIs.

For number-driven leaders, lack of a quantifiable framework to measure and monitor the impact of a new methodology is a challenge. Some leaders are good at adopting new ways of doing things and others are not. In these cases, isolate a project that you can’t measure and start small. Contain the risk but pick a project that has significant upside, to keep people engaged and motivated. You may still fail, or not achieve a desired outcome, but that’s what the design thinking is all about.

It’s worth noting that Agile, as a software project methodology, has well defined quality and reliability KPIs such as beta defects, rejected stories during a scrum cycle, and the delta between committed and delivered stories.

Fail early and course correct the next time. Remember that adoption and specific practice need correction and not the method itself. Don’t give up.

FINAL THOUGHTS

During my extensive work on design thinking - practicing, coaching, and analyzing — I often talk with people who believe that design thinking is merely a methodology or approach for “visual design.” This view is a false perception. Design thinking comprises a set of principles one can apply during any stage of the enterprise project lifecycle along with other project management methodologies. This approach is valid for the CEO and executive management all the way to the grass roots.

Another common point of confusion is the distinction between design thinking and Agile methods of software development. The primary difference is that Agile offers a specific set of prescriptive processes while design thinking encapsulates a set of guidelines and general principles. Although not the same, the two approaches are highly complementary (even on the same project), because both recognize the benefits of using iterative work cycles to pursue customer-centric goals.

Always remember that real people work on every project. The best methodologies are inherently people-centric and help participants anticipate likely causes of failure. Visualizing failure early in a project is an excellent means to prevent it from occurring. We’re all human and may make mistakes but certainly no one wants to fail.

Design thinking can make potential failure a learning tool and not a final outcome.

_______

I had originally published this post as a guest blog post on Michael Krigsman's IT Project Failures blog

Coming To A Place Near You: A Private Cloud Spiked With Big Data

Netflix similarity map

Yesterday, I moderated a couple of panels at the Big Data Cloud event. I have been a keynote speaker, panelist, moderator, and participant for many conferences in the last few years. It has always been a pleasure to see the cloud and big data becoming more and more mainstream. Here are my quick observations and insights from the event:

Private cloud getting momentum: As a public cloud proponent I thought I would never have to write this. But lately I have seen more and more interest in private cloud; new start-ups, established cloud vendors, and large legacy vendors are designing private or hybrid cloud solutions. Vendors have recognized that prospects and customers have started to take cloud very seriously but they still have the same concerns what they had few years back: security, moving data to public cloud, and giving up control. I am not interested in the private/public debate (though I do love to mess with fellow clouderati on Twitter on this topic). My take on this trend is that the vendors should do whatever it takes to move the organizations to the cloud, private or public. Once companies dip their toes, they themselves will realize what's good for them.

Big Data as a serious category: A few days back, I blogged about big data going mainstream. Coming out from this event, it felt like, today Big Data is where cloud was a couple of years back. When I asked people a few years back "What's Hadoop?" They would reply "Huh?" Now, everyone wants to know more about Hadoop, Hive, HBase, S4, Oozie, Pig, Cassandra, and other big data frameworks. They're interested in analyzing and comparing available solutions. They're asking all the right questions. The VC investment in this category has been record high. Hadoop World was a sold out event this year with 1500 participants. Milind Bhandarkar, Chief Architect with Greenplum Labs, mentioned that in 2008, during the first Hadoop summit, they had to coax people to come to the summit. The people who willingly came to the summit either worked for Yahoo or Facebook. We have come a long way and there's a long way to go but this is a rock solid category. As the first set of big data infrastructure companies settle in we will see people building killer applications and PaaS solutions specifically designed to leverage big data. It is encouraging to see more and more companies and venture capitalists recognizing that the data is worth a lot more if they have the right tools and right people — the data scientists — to do something interesting with it. For example, Greylock partners have hired DJ Patil as a "data scientist in residence" to help them with evaluating their opportunities and advising their portfolio companies on big data strategies.

Rise in popularity of open source frameworks: If you follow the history of open source you'll realize that when a proprietary way of doing things become popular, commercial vendors pose a lock-in threat, and things don't work as expected, developers get frustrated and start to work on filling that gap by building open source technology. Linux started that way and so were many other open source projects. This is why I am excited to see OpenStack gaining rapid momentum. It's slowly becoming a de-facto standard to build a commercial cloud solutions. I also like Cloud Foundry since many companies that I know of, ISVs and large IT shops, won't use a public PaaS. They would prefer to launch their own PaaS solution in the cloud. Without an open source solution, it does become a big challenge.

Early Signs Of Big Data Going Mainstream

Today, Cloudera announced a new $40m funding round to scale their sales and marketing efforts and a partnership with NetApp where NetApp will resell Cloudera's Hadoop as part of their solution portfolio. These both announcements are critical to where the cloud and Big Data are headed.

Big Data going mainstream: Hadoop and MapReduce are not only meant for Google, Yahoo, and fancy Silicon Valley start-ups. People have recognized that there's a wider market for Hadoop for consumer as well as enterprise software applications. As I have argued before Hadoop and Cloud is a match made in heaven. I blogged about Cloudera and the rising demand of data-centric massive parallel processing almost 2.5 years back, Obviously, we have come a long way. The latest Hadoop conference is completely sold out. It's good to see the early signs of Hadoop going mainstream. I am expecting to see similar success for companies such as Datastax (previously Riptano) which is a "Cloudera for Cassandra."

Storage is a mega-growth category: We are barely scratching the surface when it comes to the growth in the storage category. Big data combined with the cloud growth is going to drive storage demand through the roof and the established storage vendors are in the best shape to take advantage of this opportunity. I wrote a cloud research report and predictions this year with a luminary analyst Ray Wang where I mentioned that cloud storage will be a hot cake and NoSQL will skyrocket. It's true this year and it's even more true next year.

Making PaaS even more exciting: PaaS is the future and Hadoop and Cassandra are not easy to deploy and program. Availability of such frameworks at lower layers makes PaaS even more exciting. I don't expect the PaaS developers to solve these problems. I expect them to work on providing a layer that exposes the underlying functionality in a declarative as well as a programmatic way to let application developers pick their choice of PaaS platform and build killer applications.

Push to the private cloud: Like it or not, availability of Hadoop from an "enterprise" vendor is going to help the private cloud vendors. NetApp has a fairly large customer base and their products are omnipresent in large private data centers. I know many companies that are interested in exploring Hadoop for a variety of their needs but are somewhat hesitant to go out to a public cloud since it requires them to move their large volume of on-premise data to the cloud. They're more likely to use a solution that comes to their data as opposed to moving their data to where a solution resides.

Bangalore Embodies The Silicon Valley

I spent a few days in Bangalore this month. This place amazes me every single time I visit it. Many people ask me whether I think Bangalore has potential to be the next Silicon Valley. I believe, it's a wrong question. There's some seriously awesome talent in India, especially in Bangalore. Don't copy the Silicon Valley. There are so many intangibles that Bangalore won't get it right. And there's no need to copy. Create a new Silicon Valley that is the best of both worlds.

If you want some good reading on what makes silicon valley the Silicon Valley, read the essay "How to be Silicon Valley" by Paul Graham. Bangalore does have some of these elements - diversity, clusters, a large number of expats etc. It's quickly becoming a true cosmopolitan city in India. You don't need to know the local language (Kannada) to live there. It does have a few good colleges such as IIM and IISC, but no IIT. The real  estate boom in Bangalore is a clear indicator of what's going on in the city with regards to the spending power of the middle class and the upper middle class. Most large IT multinationals have a campus in Bangalore. The companies such as Accenture have more people in Bangalore than in the US.

So, what's wrong?

Lack of entrepreneurial mentorship

If you go back to the roots of the early success of the Silicon Valley you will find that the venture capitalists community mentored the entrepreneurs to bring innovation to life. Steve Jobs had an idea, but no business plan. Some of the entrepreneurs became serial entrepreneurs and some became the investors who in turn mentored other entrepreneurs. This cycle continued. I don't see this in Bangalore. Not only the VC funding is not easily accessible (more on this below), but there are no early investors that I see are spotting the trends and mentoring the entrepreneurs.

I spoke to many entrepreneurs in Bangalore. Let me tell you - they do not lack the entrepreneurial spirit. They are hungry and they are foolish. And they are chomping at the bit to work on an exciting idea, but they do lack someone to mentor them and take them through the journey.

Where have all the designers gone?

A couple of years ago I was invited at the National Institute of the Design (NID), a premier design school in India, for a guest lecture. They told me that design is not a discipline that easily attracts good talent in India. They are competing with the engineering schools. India lacks designers. This is the age of experience start-ups. A very few engineers have the right design mindset. If they want to be successful, they absolutely need to work with the designers who are impossible to find and hire. This talent gap is hurting to manifest the vision of a founder into a product that the consumers would love to use. Flipkart and Red Bus are my favorite start-ups but they are few and far between.

Math and Science would only take you so far

It's not just Math and Science that has created the Silicon Valley. It's the right balance of creativity, business acumen, and engineering talent. The schools in India, even today, are not set up to let students be more creative. They are still fixated on Math and Science since they guarantee good jobs. The Silicon Valley entrepreneurs followed their dreams. In the US, it's about studying what you like and chase a career that you are happy with and not to pick a certain kind of education just because they provide good jobs. Unfortunately, creativity is hard to teach. It's ingrained into the culture, society, and the systems. If India has to get this right, this needs to start at the education and a support system that has a place for jobs other than Math and Science.

I have been following the education reforms in India and private sector investment into K-12 schools. They are encouraging. I don't believe Bangalore or India for that matter will have math or science issue anytime soon, but it will certainly have entrepreneurial issues to jump start new companies and manage their ever growing engineering workforce. I was invited to speak at IIM Ahmedabad, one of the best business schools in India. During my conversation with the faculties, I was told that the most pressing issue for the elite business schools in India is to scale their efforts to create the new class of mid-management that can manage the rapidly growing skilled workforce.

Obama keeps saying more and more people in the US should study math and science to be competitive. I don't believe that's the real competition. The real competition is what can you do if you did know math and science or if you had access to people who knew it.

Lack of streamlined access to capital

A lot has been written about this obvious issue and I don't want to beat this further. I just want to highlight that despite of all the money that the individuals and large corporations have earned in India, a very little is being invested into venture capital since the VC framework, processes, and the regulations aren't as streamlined. It's not a level playing field. In the Silicon Valley, the venture money is commodity. If you have a great idea, team, or a product, the investors will run after you to invest into your company. Bangalore is far from this situation. But it shouldn't have to be. What's missing is not the available money but a class of people who can run local funds by investing into the right start-ups. Most US VC firms have set up shops in India, but I don't think that's enough to foster innovation at the grassroots level. Bangalore needs Indian firms to recognize the need for a local VC community that can work with the system to make those funds available to the entrepreneurs.

The picture: I took this picture inside one of the SAP buildings in Bangalore during the week before Diwali.

Make To Think And Think To Make

I'm a passionate design thinker and I practice design thinking at any and all opportunities. Design thinking is part art and part science. John Maeda is one of my favorite thought leaders on design. He published a post talking about art as a form of asking "what do I want to know" rather than "what do I want to say."

As a product manager, making a product goes from what do I want to know — the requirements — to what do I want to say — manifestation of the requirements into a working product. I call it "Make to think and think to make". I make prototypes — make to think — similar to a form of an art, to help me think and ask the right questions to fulfill my needs of "what I want to know". The human beings better respond to tangible artifacts as opposed to abstract questions. These conversations stimulate my thinking to execute on those requirements — "think to make" — similar to "what do I want to say." The design thinking cycle continues.