Great product teams play bingo, not basketball


I totally admit that I drive product folks crazy. I am a huge believer that it is the responsibility of every person in a company to help ensure complexity and gratuitous innovation don’t creep into a product. If you can’t answer the “so what” about something you are adding, perhaps you are adding the wrong thing. I also believe that tech writers and customer service folks are the best gauges of this pitfall, and should be consulted before you start gathering real customer feedback about how you are doing on with keeping it simple.

If it takes pages to describe a product, then it’s probably too complex. If your customer service team starts talking about the knowledge base articles they will have to write to help a customer complete a task, you probably missed the mark. If your marketing team struggles to write a solution brief or use case for parts of your product, perhaps those features aren’t as useful as you thought, and they might need to be enhanced to make their value clearer.

The message here is that there are warning signs throughout the product lifecycle that can stop you from complicating your customers’ lives, before you ever enter customer trials. As part of a product team, you need to listen to these signals. Customer feedback is critical, but you should always be designing and building with customers in mind.

This all begins with not thinking about a product as a set of features. This will cause you to create silos of functionality that perhaps don’t solve any problems. I have been known to rant that great product people prefer bingo to basketball. Basketball is about points on the board; the team with the most points wins. Bingo is about completing something as efficiently as possible. Product folks who play basketball end up with a ton of features, but no solutions. Folks who are playing bingo complete something from end to end. It’s better to complete a few major things than to have a bunch of cool stuff that doesn’t really solve any problems.

Products go awry when teams start with product requirements that appear as a bunch of puzzle pieces. They look a lot like a five-year-old’s holiday wish list –  filled with lots of things, most of which will never get used and are likely not appropriate for the solution’s goal. If you focus on a subset, you may find yourself with nothing useful: crayons without paper, or bike without wheels.  I have seen this happen multiple times in my career. People work really hard to complete the tasks, but in the end they don’t end up with a full product.

Product requirements should start with simple use cases and a test case to confirm if you achieved the goal. For example, begin with a real-world customer problem, like ransomware. IT must have tools that are able to detect ransomware when it’s triggered, and recover from it quickly, without paying the ransom. You can break this down further to determine how you will detect the trigger, and how you will recover. From there, you can write workflows for the user to follow. If you end up with a ton of steps, you need to rethink your solution. For these types of problems you can set hard limits:

  • Time to detection: “We are going to detect ransomware within X minutes after it’s triggered.”
  • Scope of the fix: “We are going to perform fine-grain remediation, only reverting files that were impacted (instead off rolling everything back in time), and we will recover in Y minutes without other products.”

This description and these limits should be enough to get your design team off and running. They know the problem, and what success looks like. Your quality assurance team can also start thinking about tests it will need to develop. These types of requirements get you to a better product. Engineering will likely grump initially, until the team gets used to thinking this way, because it was used to getting a long set of requirements to meet. However, that approach typically results in the team providing a solution to the problem statement instead of the problem statement and success. When you move away from basketball, over time, it’s freeing to understand what bingo looks like.

So, what is the meaning of the graphic in this blog? I had this made a few years ago, as it was a fitting analogy for the problem-solving model. The first panel is the problem: birds keep flying into the window and splattering (great visual image). There are elaborate solutions that will likely harm the poor birds, resulting in them dying in an equally gruesome way. There’s also the simple solution, which has you putting something visual on the window so that the bird knows there’s a solid there (the glass). Both solutions work, and the bird won’t fly into the window anymore. If that was the goal, both accomplish the mission. If the goal was to ensure birds didn’t die as part of this experiment, only one of the solutions was viable.

I can’t say you’ll always get things right, but if you are tenacious about rooting out complexity and focus on what will ultimately provide value to your customers, you will be a big step ahead in achieving customer delight and business success.

Read more of Paula’s blogs for further insights on keeping the customer front and center.   


Paula Long

Paula Long is the CEO and co-founder of DataGravity. She previously co-founded storage provider EqualLogic, which was acquired by Dell for $1.4 billion in 2008. She remained at Dell as vice president of storage until 2010. Prior to EqualLogic, she served in engineering management positions at Allaire Corporation and oversaw the ClusterCATS product line at Bright Tiger Technologies. She is a graduate of Westfield State College.