Does Building a (CRM) Platform Fit within a Lean or Design Thinking Approach?
A key initiative here at SugarCRM is to provide to our customers a platform that allows them to create and support extraordinary relationships with their own customers. In the spirit of sharing best practices, we wanted to publish some ideas on how we approach designing and building our platform to meet this objective. True to the philosophy is breaking down the problem and then putting it back together in a way that helps us to reach the best possible outcome.
Background
Designing and building a software application is no easy feat, if it were easy, anyone could do it (well). While many companies have become quite good at managing and building product features leveraging Agile methods, Agile is specific to a specific part of the production lifecycle. Figuring out what the user community actually wants, and going through iterations in design is a different matter all together. In order to attack this issue the two methods that have come into favor during the past 10 years are both Lean and Design Thinking. There are strengths and weakness to both, but what if we take the best parts of each?
It is important to outline the basic principles for each Lean and Design Thinking. Yes, there are many books written on each, clearly a paragraph does not do justice, but will suffice. A Lean focused product development approach works towards creating a minimal viable product (known as MVP) and leverages data and specific feedback throughout the design and development process. Lean takes a feature/function approach to the product as well, more on that in a bit. Lean is considered a fast, efficient approach to the whole process, as depicted below:
Design thinking puts more emphasis on empathy and creating a stronger bond with the target end-user and the job the user needs to get done with the product in question. This is also known as a Service Design or a jobs-to-be-done philosophy. Where Lean is closer to quantitative, Design Thinking is qualitative. Where Lean is logical and detailed, Design thinking is emotional, detailed and places the product in question within a larger context; the future, my business, the world around us. Visually, Design Thinking looks like the picture below, note the differences from the picture above:
In designing and building a platform for a large enterprise, it is harder to think in terms of MVP, because the team is not designing or redesigning the entire product. In this case the team needs to create another vehicle in order figure out what to build, when to build it, and whether it will work (to satisfy our customers).
With respect to building or enhancing an Enterprise platform, should the team choose an approach that favors Lean, or one that uses Design Thinking?
Both.
Resetting the Baseline
In order to make my case, it is important to redefine the rules, if only a little bit. Taking a moment to discuss exactly what “minimum viable product” describes is important to this discussion. By definition an MVP has just enough features to gather validated learning about the product and its continued development. While, by definition, MVP needs to deliver just enough of a desired outcome for people to want to sign up and use it, within a Fortune 500 organization, the bar is quite high. The baseline for MVP within the Enterprise domain is different. So much so that it cannot be ignored. Is it possible to look at this from a feature-by-feature perspective?
In the world of Enterprise Software, there is not one target user (persona), there are many more. Enterprise applications live on a technology stack, and often have domain areas of functionality. Within the spectrum of Enterprise users, some are very analytical, logical and perform tasks in a very specific way, these jobs-to-be-done require repeatability and precision. For others, there is a strong emotional element, efficiency and creativity are a high priority; like sales people for example. For this reason, this reason alone it is enough to now make the statement that one method cannot work. In an Enterprise fast, iterative, quantitative and qualitative design, along with a strong empathetic bond is required to build the right stuff.
Here are the three groups Enterprise application designers and developers need to keep in mind as they design and build software (using CRM as an example):
- End-User – Sales, Service or Marketing user, I need CRM to get my job done.
- Designer/Developer – Configuration, Customization, Integration
- Technology Support – Raw iron (or VM) up to Application layer; OS, DB, PHP
A balanced approach to each of the personas is required to design, build and deploy software that meets the needs of all three types. The balance in approach needs to come not only from how the process takes place, but whom the team talks to and how the discussion takes place. The question of approach may need to pivot towards the question of how best to get user input into the process, again, not a simple task.
What is Feedback?
“If I asked my customers what they wanted, they would say faster horses,” attributed to Henry Ford – though he never said it, and many are not sure if it was good or bad. In other words, the job that needed to be done was to get from point a to point b, Ford was selling cars, something very new.
Some might contend that the key difference between Lean and Design Thinking is one of practicality and science versus wants and desires. The quote above, whether factual or not does represent how Ford approached the automotive industry. However, the factory model he built created his legacy and nearly caused its downfall. It was rigid and hard to change. General Motors came at Ford pretty hard in the late 1920s. In 1921, the Ford Motor Company sold about 2/3 of all the cars built in the U.S. By 1926, this share had fallen to approximately 1/3. (5)
The practical value of when and how to listen to customers and/or users is a very complex problem. Any designer/builder of enterprise software should have detailed understanding of their customers and their customer’s problems via both empirical knowledge and observable patterns; domain expertise is a definite nice-to-have. In the end, the team should also feel empowered to ignore customer input, as the difference between ‘want’ and ‘need’ is often lost in the day to day within many organizations. The emotional attachment to features and functions needs to be heard and considered, but in the end tough decisions made.
Thoughts anyone?
Sources for the discussion:
1 – https://medium.com/art-marketing/lean-vs-design-thinking-6ae7c04453a6#.7ue9w2px9
3- https://www.linkedin.com/pulse/reuse-lose-many-uses-stan-garfield
4 – https://hbr.org/2011/08/henry-ford-never-said-the-fast