Traditional Approach to Design Thinking

The Traditional Approach before Design Thinking became mainstream for evaluating any business proposition, consisted of two most important aspects: (1) viability and (2) feasibility. That approach looked at the business benefits of a proposal (viability) and then evaluated whether it was doable (viability) in a financially practical manner (either through using resources of the organization or partnering with a player that could give them a speed advantage) in a timely fashion (feasibility). The initiative which ranked the highest on these two metrics was blessed with funding and kicked off. It seemed like a very reasonable way of solving problems. However, if you ask about the journey of any successful start-up, you’ll realize that not a single one followed that approach. They didn’t have the business value focus at the start of their venture. Nor did they have all the feasibility aspects figured out before kicking the project off. They had to go through tens and even hundreds of iterations before they could finally deliver enough value that was useful for their primary stakeholders/users. Even if you have an objective analysis of the effectiveness of that approach in established businesses, you will realize that almost all of the initiatives did not live up to their expectations. Why did the business world continue to use that approach even if it wasn’t effective? There are several reasons:
1. Both viability and feasibility are based on futuristic projections based on subjective judgments that are, in turn, based on faulty assumptions of the sponsor. Any projections by nature are fictitious and do not take into consideration the variability induced through changing parameters. These parameters are both internal as well as external.
2. The approach follows waterfall methodology* to plan for a long time, implement for an even longer time and then shove the solution down users’ throats. Spending a tremendous amount of resources in planning
and presenting takes precedence over recognition of assumptions and testing for validation.
3. The approach is usually compartmentalized and uses silo-ed thinking. Different teams provide their inputs from their narrow perspectives. These teams include finance, R&D, marketing, sales and operations, and they fail to recognize the interdependencies of all these disciplines.
4. The approach takes time. It can be months or even years before key stakeholders see a solution. Requirements are consolidated in a spreadsheet where importance is given to the functional feature rather than the use by the user. The sponsor is fixated only on how to plan and create the corresponding features in the product to satisfy the list of requirements. This takes a long time, as all the kinks have to be straightened out on paper first so that each department can give its seal of approval before development can start. Once the scope is agreed upon, development is started, which again takes a silo-ed approach. In technology projects, the various teams work independently in building their capabilities, which are set forth in the specification document. These teams include infrastructure, database, application, user interface and integration. The final project, though it works, fails to satisfy the end users.
5. The approach is focused on “How” and “What,” but rarely addresses “Why.” Rather than stepping back and asking the questions such as “Why is this feature useful for the user?” or “What are the users’ needs?”, the focus is on “What features do we need to add?” and “How should we build the features?”

However, like any other field, Design Thinking has evolved from the Traditional Approach to a more modern one. Check The New Design Thinking Approach post.