In the book, Art & Fear: Observations On the Perils (and Rewards) of Artmaking, a story is told of a ceramics teacher that ran an interesting experiment. He told half his students they would be graded solely on the quantity of their work. The more they produced, the higher their grade. The other half were told they would be graded on the quality of their work. A student only needed to produce one pot to earn an A, provided it was of perfect quality. Which group do you think produced the best quality pots?

Those students who focused on quantity produced the best quality pots. 

How could a focus on quantity produce better quality? You know from experience that rushing produces defects in software development. That is the problem with deadlines — teams skimp on quality or functionality to meet the deadline. 

On the other hand, the more you do something, the better you get at it. That’s certainly true for me. The students in the experiment benefited from the empirical approach of “do, experience, learn, and adjust.” Your software applications will benefit from the same approach. The trick is to use that learning, and those defects, in a positive way.

I’ve coached product management, strategy, and Agile ways of working for years. This ceramics experiment is a reminder of 3 key principles.

Anything Worth Doing is Worth Doing Poorly

Not having all the answers is not a good excuse for not proceeding. You will never have all the answers up front. Value is only known after you deploy. You can’t learn if you don’t do and experience.

You may prefer the saying, “anything worth doing is worth doing right,” because it feels better. After all, who wants to do something poorly? I’m not suggesting doing anything poorly. It’s not poor quality I’m talking about, but rather your outcomes won’t always match expectations. The point is, don’t let the fear of not knowing enough or being good enough (yet) stop you from pursuing what’s important. 

Getting started and learning is better than excessive analysis and going slow for fear of making a mistake. If a thing is worth pursuing, it’s worth starting now. Like the pot story, quickly produce something to assess, learn from, and adjust. Not sure what your users want? Get a prototype in front of them for feedback. You don’t have to “turn in” your first iteration. This allows you to work through your assumptions and refine your solution. 

The key is to just get started.

Work From Assumptions

You’re probably better at estimating value up front today than what Microsoft learned many years ago — that 60–90% of ideas do not improve the metric they intended to improve. Once an idea was implemented and validated post-deployment, Microsoft learned they weren’t very good at knowing the true value of an idea up front. If you’re being honest, you’ll agree that you also struggle to know for sure what the best thing to do is in the beginning. That’s why you are stronger when you admit that you should work from assumptions that need validating rather than known requirements.

Think back to how projects used to be done. The goal was to try and get it right with perfect quality in one shot (one pot). This is why there were long requirements phases and detailed design sessions before development work ever started. Teams focused on trying to get it right the first time — in one shot. You know the outcome of that approach. Requirements were really just assumptions that proved incorrect after all the work was delivered. Learning cycles were long and costly.

Consider this — if you deliver a “requirement” and it’s expected to improve some metric, but doesn’t, could you still say it was “required?” Or, was it an assumption that missed the mark?

The key is to understand that value can only be known post-deployment, through validation. Given that, you should then work from assumptions that need to be validated. The sooner you can test your assumptions, the better.

It’s All About an Empirical Approach

An Agile approach gets started, learns, and adjusts — it produces many increments (pots). The goal is short learning cycles. The more you work toward a solution, the better the solution becomes. It is not always perfect or right at first, but it never will be until you get started and get better. 

Quantity leading to improved quality applies to getting better at knowing your customer, just as much as improving tactical skills. The more you put in front of them, the more you talk with them, the more you understand their needs, the better you will become at solving their problems. Knowing what the next right thing is takes as much quantitative practice as building features.

Real-life circumstances rarely align perfectly with pre-planning. Can I get an amen? I’ve made assumptions and spent a lot of time planning only to find my assumptions were wrong to begin with. I find this to be true in just about everything I do. I get better as I go; I get better as I learn. Despite taking my time to think it through, measuring twice to cut once, or going slowly, the first bits of my work have always been the worst. I always get better as I go because I benefit from doing, experiencing, learning, and adjusting. Can you relate?

The key is to iterate in short learning cycles. 

In Conclusion

The next time you’re inclined to take more time to “get it right,” or you feel like it’s a one-shot opportunity to deliver the best quality, remember this ceramics class experiment. If it’s worth doing, get started on something now. Forget requirements and see them as assumptions that need validating. You will get better as you do, learn from experience, and let the small learnings lead to impactful adjustments over time. You will rarely be 100% right up front, so the quicker you can test your assumptions, the better. The more frequent your learning cycle, the better your outcomes. Quality indeed comes through quantity from that perspective.

———-

Sign up for my email list and receive weekly insights on strategic management, product management, and Agile.