In his best-selling book Outliers, Malcolm Gladwell popularised the notion of the ‘10,000 hour rule’. Drawing on research done by a Swedish psychologist, Gladwell constructed a narrative around the idea that mastery of any skill needs roughly 10,000 hours of practice. It was an attractive idea, one that built upon the already well-accepted notion that ‘practice makes perfect’. You now could plan your path to mastery, set up daily goals for deliberate practice that would lead, eventually, to perfection.
This is completely wrong, says David Epstein in his book Range: How Generalists Triumph in a Specialized World. Or at least that’s what the book’s blurb says. The book itself is more nuanced, and suggests that such a rule is true only in a very limited sense.
Epstein divides the world into two types of domains: kind and wicked. Kind domains are simple, one-dimensional fields with clear rules, where patterns repeat and feedback is fast and accurate. Playing the piano, playing chess, or playing golf are some examples of such domains, where deliberate practice can improve performance. Wicked domains, on the other hand, are those where patterns don’t repeat, rules are unclear or incomplete, and feedback is often delayed or inaccurate. Most real-world domains fall under this category. Research, medicine, education, management, parenting: these are complex domains where there’s no well-defined path to mastery. 10,000 hours of deliberate practice do not help here — on the contrary, expertise and specialisation in these domains may even worsen performance in certain contexts.
What matters in these wicked domains, Epstein says, is “range”. How much experience you have in fields unrelated to your work; how much of an outsider you are; how well you can integrate diverse perspectives of experts you work with; how much of a lateral thinker you are; how appropriately you choose to drop standard best practices; how well you can see connections between fields — in short, how much of a generalist you are.
Continue reading “Range over Mastery”
This piece was first published on Mind the Product.
One of the interesting things about developing software in the Business-to-Business (B2B) space is that you often don’t know what users need, even when you think you do. Such blind spots may not be entirely your fault.
Early in my career, I developed a software distribution tool for a CRM solution that ran on the salesperson’s laptop. (This was long before web-based applications became the norm.) To update the software on the laptop, I had assumed the availability of administrator privileges inherited from the logged-in user. But soon after the first version was released, I received worrying news: due to company policy, some customers did not give their salespeople admin privileges on their laptops. These customers hadn’t figured among those we had interviewed, but they were important. We went back to the drawing board and designed a solution that worked transparently to the logged-in user who didn’t have admin rights.
Let’s examine why this happened.
Blind Spots Caused by Poor Understanding
Simulating B2B software environments can be tricky. It can include a network of interdependent B2B applications — a complex landscape. Business processes can span different roles and can run for a long time. There may be company-specific policies that govern software usage. Users may work not in offices but in spaces like a factory floor or an oil rig. To understand a user’s needs you first need to simulate her environment, which is not easy in the B2B space.
As the CRM example showed, this lack of understanding leads to blind spots in our thinking.
B2B software is also complex. Not for its own sake, but simply because the reality it tries to model and automate — those real businesses — is complex. One way to manage that complexity is to break the solution into smaller modules or applications, each of which is designed, developed, and delivered independently by a small team. While such teams can be efficient, they often miss the big picture and don’t quite see how their local module is used in the context of the larger product.
This again results in blind spots. And the impact here goes beyond user-experience.
Continue reading “The Blind Spots of B2B Product Vendors (And How to Fix Them)”