Category Archives: New Product Development

Design Vs. Innovation?

Look around. If you live in a concrete jungle, try to move outdoors and get a bit closer to the nature – you will probably appreciate this blog post better, and might even get more out of it than this blog post!

There is plenty of sunshine (hopefully you live someplace with loads of it!). The eternal source of energy and life without which we might simply be frozen back into an ice age, and might never survive as living beings. The sunlight makes photosynthesis possible, and though there is no such direct comparable with human beings, we simply need it! Lack of sunlight could be bad or even fatal, but excess of it could cause problems as well. So, what’s the best way to enjoy sunshine? Just 10-15 minutes of daily exposure can create enough Vitamin D naturally that your body needs.

Let’s keep moving.

You see sources of life-giving water – small rainfed streams or perennial rivulets that carry the life-giving natural resource not just in the form of water, but also minutest amounts of those vital nutrients that our body must simply have in order to keep functioning well. Unfortunately, we have taken it for granted for last few centuries of industrial growth, and who knows – we might be condemned to drink recycled water in future! We can’t survive without it for more than a few days (and check out the rule of threes for some interesting trivia on it). And yet, having water aplenty doesn’t mean we drink all we can, for an excess of it can cause water intoxication, which can lead to other problems – even death!

OK, let’s go a bit more further.

There is something that we feel all around us, and yet never see it. Yes, the air that distinguishes us from other planets that have no lifeform on it. A few seconds without oxygen, and we will be all but dead, and yet too much of it can cause oxygen toxicity.

What are we driving at?

Take any natural resourcesunlight, water, air, heat, cold, heights, depths, or a common human habit like seating, walking, sleeping, working, exercising, even video gaming, or any form of intakeeating, drinking, meat, spices, sweet, fatty, fast food, soda, alcohol, vitamin, and so on. While a lack of it could cause short-term challenges and even be potentially health-damaging in the long-run (though it might not be the same case in, say, soda or fast good or video gaming), the excess of it could cause yet another set of problems, often manifesting in the long run (and hence they tend to get trivialized,perhaps).

So, what’s the point?

Nature seeks balance.

A mere abundance of any natural resource doesn’t make us overconsume it beyond what is needed by a healthy human body. The best of us create a quality of life by maintaining a wise balance between the near-term gratificationsvs. a wisely thought-out ‘no’ for the sake of long-term sustenance. Yes, sometimes we all lose that balance, but the ones who are able to quickly able to recover from their occasional indulgences finally get to enjoy life to the hilt.

Ok, but what’s the point here?

Just like nature creates a high-quality life by creating a balance – which essentially means removing the excess till it is just about right – we need to understand and imbibe it in developing products too. For example, just because you have all the real estate available on the web page, you don’t actually end up using it, of if you like purple-pink combination, you don’t end up using that everywhere on your web site. Rather, using it judiciously lends itself to a much more aesthetically appealing design. Examples are well known, like the web interface or Apple’s user interfaces starting with iPod. Long back, perhaps in late 90s, I was at the Philips Medical System’s training center in Best, Netherlands. We first saw the console of one of the modalities, it was like200 control knobs on it – perhaps operating such a machine was more complex then the surgery itself! However, Philips realized that such overengineered product was not really user-friendly and then redesigned the entire console that has just two knobs. Now, that was a major paradigm shift back then.

Steve Jobs said this as the Apple Worldwide Developer’s Conference in 1997-

People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.

You might have seen the so-called featuritis curve that is a comical take on how the user satisfaction first goes up as features are added to a product. However, the user satisfaction then comes down rapidly as even more features are added to the product, eventually leading more to dissatisfaction than satisfaction.

The Featuritis CurveHere’s the thing – it is not just valid for products meant for customers – I have seen this pattern repeatedly holding out for much more mundane things as well. Take software process. Long back, when I used to work for companies that adopted CMM or ISO9000 as framework for process improvement, we ended up creating voluminous process documents. We even had over one and a half dozen metrics to show how serious we were about process improvement. Over time, we learnt (at least I surely learnt) that process is not about adding things but about removing things that don’t make sense. In that spirit, I believe that the size of your process documents must reduce as you gain more mastery over the process – just like how it should be for a product. Some of the guidance for a product owner says remove one feature every week until the time you feel there is nothing that can be removed from the product anymore.

So, what is design then? And how does it relate to innovation? We seem to use these terms very liberally and sometimes it is not clear how do they co-exist in a single context. Here’s my perspective: design is about eliminating things that are too distracting or confusing to the user so that the end result conforms to its end-users expectations about its utility and usability, and in some cases, it exceeds those expectations. However, a good design might not always sell – the world is full of examples that the designer thought was a cool idea but the customers couldn’t care less! So, we clearly can’t party on design alone! We need innovation which is all about figuring out what the users want, and then Development / Execution on how best to deliver those features or services to them at the desirable price-point. While Innovation addresses the ‘what’ aspect of a product or a service, Design addresses the ‘how’ aspects, and Design Thinking must address the ‘why’ aspect  – there is no point bullnosing something without first establishing why do we need something in the first place. I don’t believe principles of design can solve that problem (though application of design thinking could lead you closer to truth, but that is not design). Design is one of the ways in which we bring about innovation, though other aspects of innovation could be brought about by things such as improving hardware resources, or bundling different services, or using low-cost components, etc. In our industry, several aspects of ‘design’ remain under the hood – for example the decision to use a private cloud or a particular database might never be known to the end-users and hence might have no direct bearing on their assessment of a product design that appeals to them, but those decisions will have a major bearing on how the end product or services impact them.

Nature has a great way to play around with both Innovation and Design and keep evolving in that process. In my mind, nature’s self-regulating behavior about eliminating the excess is all about creating a sense of design such that we experience bliss without either overconsuming those previous natural resources, not starve ourselves without them. It is likely that a good design will actually impede further innovation because innovation can lead to departure from established standards of design – howsomuch good they might be! So, there has to be a sense of balance between these two forces as well – one is liberating beyond the known boundaries, while the other is putting constraints on those liberties and building something that is of utility and is usable for intended users. 

However, it is worth thinking how did nature ‘stumble’ upon those balances? For example, how did nature ‘discover’ the golden ratio or the value of pi? Why is pi not an integer, or why there is a notion of health and ageing as opposed to perpetual yough, and so on. Surely this is an endless topic. But starting with big bang (or whatever else makes sense), nature must have had to experiment bigtime to start with lower lifeforms to end up with what we have today. Do we know if evolution of species has stopped, and if one were to come back to earth after half a million years, we would still see the same species, by and large? We don’t know, but certainly the evolution can’t happen without breaking the established boundaries and conventional rules of creation? So, is promiscuity is the key to evolution, and I say that in the broadest sense as a means of experimentation as a source of learning, not just for some fanciful one-night stands!

Even the ideas need to procreate in order to produce better ideas! Innovation tells which ideas should procreate, and Design tells how they should procreate! They both must be present in a ‘cooptetive’ manner – competing and yet collaborating at the same time. If Innovation always wins, we will have chaos because there will be high amount of uncertainty, change, failures and very frequent learning curves. On the other hand, if Design wins everytime, we might all end up thinking, dressing, behaving alike? I think both of these extremes are dangerous, and successful initiative is all about recognizing the power of these two opposing and yet complementary forces that collectively bring the best out of a product or service…and even our lives!

Dude, where’s my customer?

I am delivering this talk at the Lean India Summit, Bangalore, Nov 15-16. Ahead of my talk, this Q&A captures some of the key ideas behind the talk.

Abstract of the talk: Startups that operate under a stealth mode achieve over 90% failure rates. While they might have bright ideas, access to top talent, adequate funding, etc., they typically fail to accomplish their original objectives. A key reason behind such spectacular failure rates is premature scaling at each stage of the startup. In this talk, we will examine the mistakes that startups make, and what we can learn from the Customer Development model proposed by Steve Blank to improve better chances of survival and growth.

Q1. You mention that premature scaling at each stage of the startup leads to failure. What is the right time to start scaling for the startup? How can the startup course correct if they realize that they have started scaling prematurely?

A:   As Steve Blank says, a startup exists to search for its business model and not to execute it, I think the right time to scale is when you have ‘discovered’ the ‘business model’. What that means is that unless you have gone through Customer Discovery and Customer Validation process and turned your hypothesis into facts based on actual market feedback, you don’t really have any need (and hence the justification) to scale up.

Why Startups Fail

If you have started scaling prematurely, I think you should stop and introspect. Ideally, stop all other marketing and sales and other activities of scaling up the product development organization, and just focus on validating your initial hypothesis. One important point to remember is that sometimes having excess cash could force one to scale up, so avoid getting more cash than you really need!

Q2. There are couple of questions we asked one of our other speakers Wes Williams, which we think is relevant to your topic as well. Would like to hear your thoughts on this – a) How does the size of an organization impact its scalability? Would you need to think of a different scalable model for large sized organizations?

A: Large organizations have typically been cash-rich and hence were more eager to scale-up in the past. However, the harsh realities of today’s economic environment have forced them to be more conservative. I believe even the largest, most cash-rich organizations are thinking twice before scaling up prematurely. I know how hard it is in most product companies to get an additional resource even, so clearly, the old rules don’t apply so well anymore.

I would build a much shorter runway where I can demonstrate tangible results in terms of customer discovery and customer validation that allow me to pitch my case for incremental funding that is backed by solid data from the market. That way, my expenses and promised revenues are growing in tandem rather than making a wild promise about the revenue without a scientific basis and piling up a large expense plan in anticipation of revenues.

Q2. b)What do you see as the difference between scalability, flexibility and agility?

A: Agility is the ability to achieve (or exceed) the set goals by being flexible about how to accomplish them. Flexibility is the means to accomplish agility as an end-goal. Even there, let me correct myself – agility is not an end-goal. It is once again a means to accomplish the next higher-order goal, viz., create a successful business.

Scalability is very different, though an effective scalability might require them both. In traditional manufacturing, it was all about building something at a large-scale so that economics of manufacturing or production could become much more affordable. The problem is that accomplishing scalability invariably requires lots of sunk costs and irreversible decisions and might be fraught with risks if the underlying assumptions turn out to be false. Henry Ford was able to reduce car prices by creating a process that eliminated user customization (“you can have any color of car as long as it is black”) to create a standard one-size-fit-all car that could be mass produced to achieve unprecedented economics of scale. However to achieve such economics of scale, he had to pump in millions of dollars in manufacturing plant and a car design that might hopefully sell in the market. So, in manufacturing, mass production brings down prices, and hence, scaling up is good, but one needs to make sure they have the product that the market wants, lest they be stuck with deadwood!

In software, scalability needs to be understood differently from manufacturing. Presently, there are two key manifestations of scalability – one is scaling-up product development process across the organization, e.g., going outside a single scrum team and aligning to the strategic portfolio, etc. One such framework that attempts to integrate all organizational functions together is Scaled Agility Framework. The other one is scaling-up your software product or services, e.g., offering the app on all major OS versions of mobile or tablets, or offering the software in all languages, or offering the product in all geographies, etc. The first one is all about being internally efficient and reduce friction and hand-offs across different departments in achieving a seamless supply chain to ‘scale up’ your agility throughout the organization and not just limiting to software teams alone. The second is all about scaling up your product and services from the market coverage or product capability standpoint and is conceptually more akin to traditional notions of scalability. One needs to be pragmatic about market potential before committing to any such expenses that involve sunk costs or are irreversible in nature. To that end, the principles of agility are a must to establish early proof points about the real assessment of market potential.

Q3. The Customer Development Manifesto suggested by Steve Blank mentions that “A Startup Is a Temporary Organization Designed to Search for A Repeatable and Scalable Business Model”. In your experience, how much of scaling is good for the organization? At what point does the startup need to pause and introspect on whether to scale any bigger, or to look for some other way to scale?

A: There is some very good data from Startup Genome Project that captures such data points. While I think such guidance is very comprehensive and highly relevant for all startups, it must not be construed as universally applicable. Take the data as a guidance and question before committing any fixed expense item whether you really need it at this point? To me, it is not any different from how one would commit to such expenses in their home or even as a group manager in a company.


Customer Development model provides a framework to systematically validate all hypothesis before going out and scaling up the startup prematurely

I meet so many entrepreneurs who build a large team – VP of Sales, VP of Marketing and even 8-10 developers before they have built a serious product to market! If you follow Steve Blank, he is very unambiguous in his guidance – during customer discovery phase, it should only be the founder of the company to validate the ‘leap of faith’ hypotheses, and no one else! I also find that sometimes getting funding early in the day could make people scale-up prematurely and that’s just as bad.

Is there an alternative to scaling up? Yes, first off, build an MVP and keep your expenses low. A key thing about the MVP is that you must aim for selling the MVP as a means to validate your Business Model – freebies don’t give the proof point that you need to turn your hypothesis into facts. Once you have a reasonable confidence backed by solid data about customer validation, then you might be better-placed scaling up.

Q4. Could you talk a bit more about the Customer Development model proposed by Steve Blank and how you are going to extrapolate from this model in your talk?

A: Traditional startups, for example during dotcom, were known for the so-called ‘stealth mode’ development where they could work for an extended period of time, often away from public glare or any meaningful form of real-world customer feedback. However, we now know such a model is fraught is too many risks. It is the Hail Mary pass of entrepreneurship! On the other hand, Customer Development model is a highly scientific approach to entrepreneurship that recognizes the need to have real-world market data before going out and building the product. In today’s time and age, technology and consumer preferences change at warp-speed, and it is no longer realistic to build a product with a long-lead time. The worst thing that can happen is to build a product that no one wants! This might appear as poetic exaggeration, but the world is literally full of such experiments. Think of McDonalds Pizza or Colgate Breakfast Entrees or Frito-Lay’s lemonade or hundreds of such products – they were all created by highly successful companies that definitely knew what it took to built new products. And yet, they all failed. Why? Because essentially, they built something that the market didn’t need. Surely, they must have done market research throughout the lifecycle, but clearly they missed something much more fundamental – product development is not simply developing a nifty idea but also entails a parallel cycle of customer development, especially in new markets. Customer Development model is one such model that helps figure out what and how to do to do customer development – whether one is a true-blue startup or a brand-new idea in an established company.

Q5. New research by Harvard Business School’s Shikhar Ghosh shows that 75% of all start-ups fail. In your experience, generally what must the remaining 25% be doing right?

A: One thing we could be safely assured they are doing well is that they are listening to early feedback and adapting to it rather than going out and building the complete product or service based on untested hypothesis. And to be able to do such adaption both effectively and efficiently, they are using short iterations where they are able to give functional products in the hands of the customers so that they can get some valuable customer feedback. Popularly known as an MVP (or a Minimum Viable Product), it allows a high degree of prioritization of features from users point of view, and an agile development process that allows creating rapid iterations of high-quality and well-test features.

Q6. If I am part of a start up like organization, operating within a giant organization with its set business models and processes (that are also required to keep the big brother organization up and operational), how does one navigate the plethora of subsidiary business groups like facilities, infrastructure, HR, etc. to enable a lean start up mode for my particular group?

A: No easy answers here! In fact, history has repeatedly shown us that the more successful an organization is, the more it is difficult to get a radically new idea going. No wonder why Sony, the undisputed leader in Trinitron technology, completely missed the Plasma and LCD display bus (before eventually joining the LED display party, even if if a bit late) or the Internet leader Google who has never quite figured out its social strategy (well, some might argue that with Google+, they do have it, but that’s one point of view). So, traditional methods of pitching an idea and expecting the upper management to bless might work in theory, but I wouldn’t rely on them.

Over year, I have found one approach that perhaps works much better compared to anything else – skunkworks. If you are truly passionate about the idea, let that passion help you ‘recruit’ other co-creators (always remember – it takes a village to raise a child) and then put your spare cycles to build a prototype to demonstrate your idea. If you are not willing to take risks and spend days and weeks in even trying the idea, why should you expect that the management will give you budget for it? It’s like going to bank asking for money, whether to buy a house or to build a company – they want you to put down some money first in the form of your contribution or a guarantee, and the logic is same – if you are not willing to take any amount of risk behind your idea, why should others do it?

Java language came out of skunkworks at Sun. And so did the first Apple Macintosh. I have seen several good ideas come out like this in large companies, though I don’t think anyone can guarantee skunkwork projects. However, on a relative basis, it is much better demonstration of the power of your idea (compared to a powerpoint deck) and your passion that might improve your chances of getting the necessary organizational support to take your idea to its next leg of journey.

Q7. Finally when is it the right time for an organization to realize that it has grown too big to be in a startup mode anymore, and might need to revisit its way of working to adapt to its current size?

A: This might be the next million-dollar challenge and I wish I knew the cookbook answer! Unfortunately, we build the bureaucracy one day at at time and before we realize, we have built an impregnable wall of self-preservation that blunts any attack on status-quo. We don’t realize it because it is like slow-boiling the frog. Initially it looks innocuous and we tend to trivialize it, until one day it becomes so huge that we can’t get rid of it even when we try so hard!

I think an organization has stopped being a startup when people stop complaining and simply give up on you, when no one volunteers and there is generally a diffusion of responsibility, when people build territories and silos, when we are intolerant of failures and anything perceived disruptive, when people want to join because of the perks of the company rather than the challenges they can work on and the impact they can create, when more time is spent in waiting for decisions rather than learning from actions following implementing those decisions, and so on…

Q8. Who is the target audience for your talk? Only startup organizations?

A: Anyone who is undertaking a new endeavor under conditions of extreme uncertainty.

Why user stories make sense?

User story is a popular mechanism used by most agile methodologies to communicate user requirements. Actually, this is only partially true. User stories are meant to be a placeholder to initiate an early conversation between the product owner and the team on key hypotheses so that a quick validation of them could be done to refine/confirm/reject our understanding of what the customer really wants. To that end, user stories are not anything like the requirements of yesterday – they are not even remotely meant to be complete/comprehensive and so on. 

The reason user stories (and not ‘well-formed’ requirements, if that is ever possible) makes sense is because we human beings are not experts in following the written word, and are likely to misinterpret requirements even when they are explicitly written down, especially when the communication is a one-time event and not an ongoing process. (if you don’t believe this, just visit this interesting site that celebrates real-life examples of how something as simple as icing on the cake can go horribly wrong despite really simple and absolutely clear instructions!). And we are talking about building complex mission-critical systems that must operate 24/7 with top speed and efficiency. If only the written word could be consistently understood by the receiver as intended by its author… 

On the other hand, if there is a continuous two-way dialog between the product owner and the agile team, such purposeful brevity leads to curiosity which then leads to a constantly improving and better shared understanding that refines as the product gets developed incrementally and gets periodic user feedback. 

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer's wants and needs.

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer’s wants and needs.

The key benefit of user stories is that instead of waiting for weeks (even months!) to get a fully-bloated and rather unprioritized PRD which is supposed to have fully-baked requirements while the development team sits idle all this time, is that identifying highest priority user stories and using them  to develop a prioritized product backlog allows the teams to get started much earlier and start developing features which could then be put out in front of customers to get real feedback (as opposed to individual ‘opinions’ that might/not best guide us in an uncertain environment). This is especially important because in the past, when the world was little less complex and much more underserved. I purposefully use this term ‘underserved’ because it is not that people have suddenly become much more demanding about what they like or not, but were just told there were exactly three carmakers to choose from, or just two operating systems to choose from, and so on. However, with rapid advancement of computing paradigms and constantly lowering cost of ubiquitous communication devices, they suddenly have the opportunity to demand what they want, and hence classical ‘forecast’ models of requirements elicitation, design or production (at least in the manufacturing sense) don’t work so effectively as much as the newer ‘feedback’ driven models that allow for developing key hypotheses (and not hard requirements carved in stone) which could then be quickly and cheaply delivered as ‘done’ features so that customers could tell us if they like them or not. Based on such valuable customer feedback, the team could iterate to either refine the feature, or to pivot, as the case might be. In the past, this might take the entire product gestation cycle, by which time, many, if not most, things might have undergone significant changes, and the entire development costs being sunk by that time, not to mention complete loss of any window of opportunity.

As Facebook says – Done is better than perfect. User stories allows developing a small slice of the product without really perfecting the entire product, but facilitates the process of validated learning that eventually helps develop a product with much higher chances of meeting customer needs.

In today’s world, you probably might not have the luxury of having investors wait multiple years for an exit, or customer waiting several quarters for a perfect product when the competition is willing to serve them faster (even letting them lay their hands on an earlier version and give feedback thus making customers a co-creator of the product), or employees working month after month without getting any meaningful feedback from customers. And we know that absence of any feedback eventually leads to erosion of trust. Incremental product development could help you bridge such trust deficit by delivering highest value to customers early and periodically, and user stories might help you get your project a quickstart.

What Emerging Markets Customers Really Want from the Internet: An Indian Perspective

[This article was published in PDMA’s magazine Visions, issue Q1 2013, based on my paper presentation at PDMA Conference 2012]


India is a new gold rush market. Home to some 1.2 Billion people, half of whom under the age 25, and buoyed by the recent economic growth, the country is poised to be a major economic powerhouse for the next few decades before becoming the second largest economy by 2050. In this short article, let’s review some of the data and trends that I discussed earlier in my presentation at the PDMA conference in Orlando, Florida.

Internet in India officially started on the 48th Independence day, 15 Aug 1995 when VSNL started offering services. However, adoption for the next ten years remained elusive largely due to poor bandwidth of the then dial-up connections and relatively high costs of computers. In 2004, government formulated broadband policy, and adoption picked up in 2005 but has always remained below worldwide averages.

[slideshare id=14856633&doc=tvpdmapim2012-121023162654-phpapp02&w=650&h=500]

Impediments and Growth

Some of the digital impediments that still hamper speedier adoption of Internet in India include poor and costly bandwidth, lack of content in Indian languages, payment and delivery issues in online retail sector and lack of one-stop e-governance solutions. Despite these formidable challenges, India today has 140m Internet users, which is roughly 10% of the population. It grew 25% from last year, and the projections are 300m Internet users by 2014.

Indian Internet CafeThis is in sharp contrast to 950m cellphone subscribers, out of which 350m have data plans, and only about 30m smartphones. The recent growth in smartphones can be attributed to the entry-level Android devices that have dramatically lowered the price-point for an Internet device, thus fuelling an entirely new category of ‘new to net’ users who will perhaps skip the desktop devices altogether.  However, this new class of users is responsible for a good 60% of the Internet access. As an example, 30% of new Facebook registrations are happening from mobile. Clearly, mobile as the default access device is a critical success factor.


Top five activities on Internet by the amount of time spent include Social Networking, Entertainment, Portals, Emails and Search. In Social Networking, Facebook is the clear winner, and India is the second largest country with 65m users that has grown eightfold in last 2 years alone. Projections are that by 2015, India will be the largest country on Facebook. Similarly on LinkedIn, it is the second largest and also on Twitter in terms of active users. Clearly, that is a growth category. In terms of Entertainment, India thrives on Bollywood and Cricket, and hence it is not a surprise that this is a highly prized category. Bollywood produces over 1,000 movies a year and Indian Cricket is the largest market for entertainment cricket (i.e., five-year old Indian Premier League that is roughly a $5Billion industry now) as well as the professional variety. Another high-growth area of infotainment is news, which is evident from literally dozens of national, regional and local news channels in a country that is also the largest DTH market in the world.

Online Retail

One category that is not in top five is the online retail. It stood at $10B in 2011, and is projected to grow to $14B this year. It had a slow start, plagued essentially by problems in payment and delivery systems, but some new trends are very promising. 80% of this comes from travel, which has been a traditional pain point in India. Other categories like books, electronics and apparels are looking up. Flipkart, an online book seller, now ships over 30,000 orders a day and is poised to be the first Indian internet company with $1Billion valuation. IRCTC, which is essentially a government owned corporation and sells railway tickets, which has been another painpoint for ages. It does close to 200m payment transactions a year for a network that carries 10Billion passengers annually.

An interesting data-point here is that a good 150m Internet users are ‘internet-ready’ but only 10m are actually shopping online. So, there is a huge opportunity to bring them online by creating innovative solutions that take the pain away from online buying cycle.


Internet breaks down barriers of pricing and distribution that have traditionally kept big multinational players away from several emerging markets. In the context of India, it is fast emerging as a high-growth vehicle for markets that have been historically underserved, even by local players. The key to success is in being able to design products that eliminate bottlenecks in the complete online buying cycle at an affordable price-point. Indian markets allows Internet-scale problems to be tested for key hypotheses, which can then also be taken for global rollouts in comparable markets globally.

The Joys of Designing Agile Solutions for New-Age Problems

Pune is hosting India’s very first Scrum Gathering this year in July with the theme of “Scrum – Kal, Aaj aur Kal“, meaning the past, present and future of Scrum. I appreciate all efforts by Madhur Khaturia and his team in making it happen. I hope and believe it will be yet another milestone in India’s journey towards agility, and will stimulate a whole lot of new ideas and conversations thus ultimately leading to increased awareness, higher adoption and more breakthrough products from India.

Scrum Gathering India Regional 2013

Scrum Gathering India Regional 2013

I got confirmation mail yesterday that my workshop on “The Joys of Designing Agile Solutions for New-Age Problems” has been accepted for Scrum Star Trek, which is the track for discussing The future of Agile Philosophy and Scrum Framework. This would focus on new techniques, methods , innovations and concepts being used by practitioners. This would have workshops, concept presentations and round-tables on future of Scrum. The other two tracks are Scrum From the Trenches and Scrum Accomplished.

I am really looking forward to this workshop. Here are a few details about it. 

Agile methods, and scrum in particular, help organize the work by prioritizing items could be done and delivered in a small timebox. While its simplicity and effectiveness is based on timeless experiences that make it an effective approach for a certain class of problems where a product backlog exists in some shape or form, and there is some basis (scientific, data-driven or otherwise) for the product owner to prioritize features, it doesn’t really offer any clear guidance for a newer class of problems where, for example, the work is so radically new that there might not be a product backlog. For that matter, there might not even be a market, a customer or a product to begin with. Think of you specifying and designing ‘something’ when no such product ever existed – not just in the minds of customer but even in the dreams of its designers! How can one have a ‘product owner’ or a product backlog when there is even no source of such information? All we have is a loose set of ‘ideas’ which might or not work. Distilling such innovative ideas in a product or a sprint backlog might be too premature. We clearly need a different approach than a thoroughbred Scrum. 

In the last few years, the work on Customer Development and Lean Startup by Steve Blank and Eric Ries has led to putting a framework in place for solving such class of “VUCA = Volatile, Uncertain, Complex and Ambiguous” problems in a more systematic and result-oriented manner. These have greatly helped startups and entrepreneurs where failure rates tend to be extremely high traditionally. In this half-day workshop, we will experience to joys of creating a product starting with Design Thinking and apply principles of Customer Development and Lean Startup and explore the nuances of designing agile solutions for such new-age problems.

Do you have experiences to share in this class of new-age problems? How do you design effective solutions that allow you to thrive on ambiguity, deal with unknowns and keep moving at lightning speeds despite maintaining a holistic sense of agility? Share back your ideas and experiences…

Does your process help you preserve status quo, or deliver some kick-ass skunk works?

Problem-solving in the past has been dominated by methods involving rigorous and meticulous planning and flawless execution – something that has been questioned, largely by results (or rather the absence of it) in the recent years, if that is (still) the best approach when there are so many moving parts and the external world changes in a blink. We frequently ‘blame’ old practices of assembly plant-style waterfall days where it took years to get a project team to jump multiple hoops and just get a project done – in most cases, hopelessly delayed, unacceptable quality and overbudget. Building process frameworks was once thought to be the panacea for all these maladies, especially in mid- to late-nineties, as we say with a series of processes – CMM, ISO, BPR, and so on… And thus, birth of agile movement came as a big relief and promise to speed and improve things up a bit. The idea of starting out with just enough requirements and iterating along with way had an intuitive appeal in this VUCA world, where no one had complete information nor all the time to wait for that perfect moment of epiphany – because that epiphany was a moving target in reality. With more efforts to design a solution, we learnt a bit more about the problem and this became an unending spiral – which was not necessarily a bad thing, but the gated processes didn’t provide much guidance on how to address it effectively. Clearly, we needed nimble processes that allowed for more iterative development without making too much commitment upfront, especially that couldn’t be easily changed downstream, and a matching sociological process that allowed teams to build unconditional levels of trust among themselves that stimulated collaboration and made them operate at the speed of light. Many of these ideas have emerged from multiple disciplines such as software development, behavioral psychology, team dynamics, systems thinking and leadership, just to name a few, in the last ten to fifteen years, and have led to statistically significant successes in several domains. However, as we are learning, some of these practices have been around for decades – just that we haven’t ‘discovered’ them just yet. I just found out one such great example this weekend – the Skunk Works. Wikipedia defines it as blow:

skunkworks project is one typically developed by a small and loosely structured group of people who research and develop a project primarily for the sake of radical innovation.[1] Everett Rogers defines skunkworks as follows: “[It] is an especially enriched environment that is intended to help a small group of individuals design a new idea by escaping routine organizational procedures. The R&D workers in a skunkworks are usually highly selected, given special resources, and work on a crash basis to create an innovation.” [2]

Clearly, developing skunk works is not a business as usual approach. It is a special quarantined environment created for the sole purpose to incubate a radically new idea under special conditions that catalyze teamwork and collaboration and accelerate innovation. Another definition describes it as:

A skunkworks (also known as Skunk Works) is a small group of people who work on a project in an unconventional way. The group’s purpose is to develop something quickly with minimal management constraints. Skunkworks are often used to initially roll out a product or service that thereafter will be developed according to usual business processes.

However, there is more to Skunk Works than this. Starting out in 1943, Skunk Works at Lockheed owes its foundation to a mantra of “quick, quiet and quality” that still continues after seventy years. The first project, XP-80 Shooting Star jet fighter was designed and built in only 143 days – seven days less than required and without any contract or an official submittal process! The formal contract for XP-80 did not arrive at Lockheed until Oct 16, 1943; four months after the work had already b

What is your skunk works process?

What is your skunk works process?

egun! However, when we look at its operational record, it was delayed – it was pressed into service only towards the end of WWII – something that clearly didn’t meet its original objective. There were many accidents, and several ace test pilots were killed on the test flights. Given that there were several innovation on this ‘product’ there seems to be a strong flavor of fail fast, fail cheap and keep iterating – even though the loss of human lives seems to be tragic and perhaps avoidable in some cases. However, this blog post is more about the underlying process and associated principles that led to such innovation in the first place. Upon reading further, I was impressed by its founder, Clarence “Kelly” L Johnson, who started it all. He broke the rules, challenging the then bureaucratic system that stifled innovation and hindered progress. I think these rules have never been so important ever before… Kelly’s 14 Rules and Practices Kelly wrote down these 14 rules that led to the successful culture of innovation at Skunk Works at Lockheed. Let’s study them and understand their context in today’s workplace, and if our practices address them effectively:

1. The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.

There must be a clear-cut responsibility, ownership and accountability lest there be diffusion of responsibility leading to confusion, chaos and associated symptoms of delays and poor quality. As much as we need self-organizing teams with democratic decision-making process, we still need to have a clearly defined ownership – someone who is tasked with breaking all rules to get the job done! Agile teams make the team responsible for delivering to its commitments, and agile thought process doesn’t generally support the notion of a ‘manager’ but a product owner is still responsible for eventual success of the product. Yes, the notion of what constitues work for a manager will keep changing with the times, but in some shape or form, I believe there has to be a sense of final responsibility for the outcome.

2. Strong but small project offices must be provided both by the military and industry.

There is no denying the importance of reducing management and administrative overheads but making them more effective. Bloated models that create large hierarchies are on a wane, and new-age program management is all about leadership by influence rather than using positional power to get the job done. Scrum takes a leaf from servent leadership to describe the role of scrummaster,  which is a significant departure from having a manager with positional power to get the job done.

3. The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).

More than the ability to actually work with small teams is the recognition that having a small team is much more productive and effective compared to the “so-called normal systems”. Of course, not all problems can be solved by having small teams, especially if one is looking to complete them faster than the competition, but one needs to weigh-in all the factors, but definitely in favor of small teams. Agile makes a strong case for small teams.

4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.

This sees like making big commitments upfront is being deemphasized. This principle sounds very simple to what Lean Construction Institute, several decades later enunciated when it said, “…design decisions will be deferred until the last responsible moment if doing so offers an opportunity to increase customer value.” Agile thinking is very much aligned to avoid making heavyweight commitments upstream, especially when there is a heavy cost of change them later, and given the rapid pace of changes around us, it is certainly not a hypothetical and extremely rare situation for which we are delaying making the decision.

5. There must be a minimum number of reports required, but important work must be recorded thoroughly.

It’s so funny to imagine that in the era of typewriters too, they were sick of reports! I think there is nothing that can justify having a disproportionate number of reports under any circumstances. The old thinking was to increase the micromanagement when in crisis, or even otherwise (I fondly remember a General Manager in at an old job who would come to our cubicle every hour and check the status update on ‘design document’!). I think asking for a number of reports smacks of Theory X, where the underlying assumption is that unless you make people work, they won’t take initiative and most certainly won’t assume responsibility. So, the hierarchy gets created simply for asking for more frequent status updates, and since the higher levels wield considerable power in deciding renumeration and career progression for the ‘lowly underlings’, who do you think wins in the end? Certainly not the project, I guess!

6. There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program.

I see no reason this doesn’t apply in any possible context. Any sponsor needs to know how is the team doing. The team owes it back to their stakeholders, management and customers to keep them posted of what is keeping them busy, and when are they likely to be finally done. When I look at agile thought movement, there was an almost anti-establishment feeling that was so palpable in numerous views on dozens of discussion forums, that it is not a surprise that agile didn’t find too many favors with ‘management’. I don’t think it is called prudent wisdom to take money from a project sponsor and tell them they are ‘chickens’ :). Thankfully, I see more maturity among agile thought leaders today, and any level of project team owes it to keep their first-level of ‘customers’ engaged through the development phase.

7. The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.

There was a time when people outsourced to save a few dollars. Not anymore. With such tight integration of your suppliers in your value chain, it is not about cost anymore – they need to have much more than their skin in the game. A strategic project can’t afford to have relationships that seldom go beyond conventional commercial considerations. Perhaps the best-known example is how Toyota treats its suppliers – “…we believe in developing mutually beneficial, long-term relationships based on mutual trust. To foster that trust, we pursue close and wide-ranging communication with suppliers.” and “…We at Toyota rely on outside suppliers for most of the parts and materials in the vehicles we make. Every step in making Toyotas, from development to production, consists of joint work with suppliers. The suppliers we seek are companies that have the will and the ability to become active partners with us. We are looking for suppliers who possess world-class competitiveness in terms of qualitycostdelivery, and technological capabilities.“. I don’t believe without such strong win-win mindset, a company can succeed in achieving the agility required to compete at big game.

8. The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don’t duplicate so much inspection.

Inspection is essentially a waste. Deming was vociferous in his views on this “Principle#3Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.”.  Clearly, there is no way we are ever going to completely do away with any form of inspections – there are far too many normal and special variations in any process to be able to run subsequent part of the process in autopilot. However, a more conscious effect to eliminate duplicacy in inspections not only improve the value stream but also fosters the culture of trust and interdependence among all players which can eventually help everyone run faster rather.

9. The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn’t, he rapidly loses his competency to design other vehicles.

If you can test components of an aircraft in initial stages, what stops you from doing the same for, say, software? Some of the biggest opposition to early testing comes from enterprise software and from software platforms – that they can’t possibly test half-baked functionality? However, nothing could be further from truth. If we are not testing product and its components early enough, we are accumulating significant risks downstream that can force untold miseries during the big-bang integration. I don’t think anyone disputes it seriously today.

10. The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.

I think there is nothing wrong with this idea. However, there is a presumption of technological stability that doesn’t hold so well anymore. The pace at which newer technology gets productized is unprecedented, and one can’t sit comfortably having zeroed-into the hardware platform at the start of the project. However, there are surely classes of problems where for regulatory reasons, the technology cycles are much longer, and hence it makes sense to be cognizant of them. However, the advise is generic enough to be universally applicable for all class of problems.

11. Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.

Simply put, if you don’t pay your suppliers on-time, they will have less motivation to work on innovating the next big thing and more to worry about how to pay salaries to their staff! Perhaps this was a big deal in early 40s that Kelly has to write it down! However, lack of funds can surely cripple or kill a project and hence enough care must be exercised, commensurate to the project size and impact, that ensures this is not on critical path. 

12. There must be mutual trust between the military project organization and the contractor, the very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.

Again, Deming has some useful advise here too “Principle #4End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.“.  While one can debate if having one single supplier is a wise thing to do, there is no doubt that one needs to build a long-term relationship on a foundation of loyalty and trust. A relationship on short-term commercial interests might hold critical projects to ransom in times of crisis, and control or coercion might  backfire. However, trust will almost always be reciprocated with accountability.

13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.

This might be more relevant in military, but in true innovation projects where a mere whiff of what are the designers thinking is likely to be significant competitive intelligence in the hands of competitors, a sense of maintaining right amount of secrecy is not unusual. Apple is well-known to maintain absolute secrecy about its new products, and goes to any lengths to protect its competitive advantage. I also think it is not just about the secrecy due to competitive reasons, a little bit of ‘confidentiality’ might actually increase the amount of buy-in from team members and make them more ‘possessive’ about their work, making them all come together. However, it’s clearly a double-edged sword, and one must choose what works for them.

14. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.

I think Kelly was either a battle-scarred veteran of performance appraisal systems (back then!) or a visionary to be able to call a spade a spade! Perhaps the conventional systems at that time rewarded people for the number of personnel supervised, which might have no bearing on ability to innovate or deliver performance. This might even be his pet peeve, because in an earlier principle, Kelly has called for smaller teams, and here he is asking for rewards to be performance-based and not based on the team size. As we have seen in last few decades, power-hungry managers have only worked towards building large self-serving empires with no relation to the nature of work. In the end, such pyramid structures has become just that pyramid-shaped ponzi schemes. However, today’s social norms and professional values don’t support such stone-age thinking, and hence, this is only a gentle reminder to today’s managers. However, it must have been very profound at the time Kelly jotted this down. While reading these 14 principles, I couldn’t help but admire the genius of the man behind it – Kelly was not only on the top of his game, he was willing to literally fight the establishment to get his job done. If he perceived his process as stifling innovation, he was willing to talk about it, and make necessary changes commensurate to what was expected of him. A lot of people take refuge under and behind the process frameworks without thinking if it meets their needs. The thought process is that you buy a certain level of performance with established processes, and hence if you fail, it must be due to the process and not entirely because of you. This gets aggravated in organizations that apportion praise on the process and management, and failure on the managers and the individuals. As a result, people stop sticking their necks out, and instead choose the trudge along the status quo. But think about it – are you paid to preserve status quo, or to push the thinking, bring about changes, break some china…in short, deliver some skunk works… So, does your process help you preserve status quo, or deliver some kick-ass skunk works?

Seeking submissions on New Product Development and Product Management in Agile world for #AgileIndia2012

Agile Alliance has announced Agile India 2012 in Bangalore, India in Feb 2012. First of all, Naresh deserves kudos for all his untiring efforts last several years bringing up and building a robust multi-city agile software community in India, and deserves all congratulations bringing the flagship Agile conference to India. As the Chair for Agile India 2012, we couldn’t have had anyone better than Naresh to lead this.

AgileIndia2012 comes to Bangalore, India in Feb 2012
AgileIndia2012 comes to Bangalore, India in Feb 2012

I had proposed the stage on Agile for New Product Development (NPD). Annu Augustine (@annua) proposed a stage on Product Management in Agile world. The organizing team proposed merging these two and we all agreed that was a great idea to create a stage on “New Product Development and Product Management in Agile world”. I believe the time is ripe to elevate agile thought process outside the software development team and apply it to the big picture – the end to end product development. We often see significant ‘productivity’ claims from software teams adopting agile practices. However, there are several other key functions involved in product development – product management, user design, marketing, sales, technical documentation, beta programs, manufacturing (at least for systems companies), and so on. If software team optimizes its software process, it is good. However, it is necessary but not sufficient to achieve end-to-end agility. If rest of the organization doesn’t change its thought process, we just end up moving the ‘constraint’ from software development to something else, and the true gains of agility might not get realized at the organization level.

In this stage, we are now seeking perspectives, experiences, insights and groundbreaking ideas from practitioners and thinkers on how they have applied the spirit of agility to create new products that have led to unprecedented and extraordinary market success compared to their previous conventional practices. Specifically, we are looking for proofpoints from the marketplace to demonstrate how software team’s agility was directly visible in business results. We want to know what you learnt from your experiences applying agility at every step of the new product development to create customer delight experiences. We want to know how did you manage to crash your time to market to deliver innovative solutions that delighted your customers, or made significant impact to their topline.

We are still working on setting up the infrastructure for submitting the ideas, but in true agile letter and spirit, we want to evolve this stage as we go. Write back to Annu or me to share your views and ideas so that we can co-evolve this stage. We want to dogfood the spirit of this session by incorporating your feedback to make this stage more useful to everyone. You can find more details on Agile India 2012 here.

Interest to submit a proposal? Click here.

Let’s get going…