Category Archives: Product Design

Building the Kitchen Sink App


No… I got the kitchen sink too.

The impulse to build a “kitchen sink” app comes from, I believe, a few places:

  • Fear that users will be disappointed with less features
  • Requirements from other stakeholders or teammates
  • Belief that mobile is a direct corresponding medium to web; what’s on the site should be on the app
  • That users come to mobile with the same expectations as desktop or browser users
  • That time and cost estimates are the same with web as mobile
  • Unclear knowledge on how long it takes to build software (vs. websites)
  • Fundamental belief that stakeholders know better what customers want

I’ve seen, up close, two different projects that began with a large spec. They had various logical and thoughtful reasons why they needed to build out big features. Justification for each case was based – not on customer feedback or metrics – but on business cases, perceived necessity, competitive advantage and financial reasons. Customer satisfaction was important, but it wasn’t a direct “they wanted this”, more of a “we believe they want this,” and more “we want this.”

I’ve also seen, up close, small applications developed with customer feedback. A lot of time is spent on planning and testing, and development is quick, and relatively simple. Customer feedback is always the number one reason features are built. There is a lovely basic, direct knowledge that customers want something, because they basically said so. Iterating quickly, getting feedback, building what they want, it’s a cycle that – when done right- results in great software.

What really gets me is when someone asks for a kitchen sink, and points to one of these small prototypes that evolved over years, as an example of what they want out of the gate.  I start telling them the story of that app- how it had modest beginnings, the missteps, the corrections, and what they see as the the final app was not, at its core, a kitchen sink app. Instead, it was a carefully crafted- by the customers- application of what they want and needed, over time. The best justification for why to do it this way, is of course, financial.

Best Reason: Money

In the two cases I talked about above, where full-featured specs were thrown over the fence “90’s style,” the projects ran way over cost. The cases where projects launched modestly and gained traction with the user base, and product direction was largely determined by necessity on the part of the customers, were very affordable. We got into a loop of launch and test, gather feedback, communicate with engineering team. Build release, launch and test, etc. This was with a live production app, as well. Yes, there were issues, there were rollbacks. There were apologies to user bases. But since their app was getting built as they wanted it, we had a very happy base that felt listened to, and catered to. Engineering was happy- the development was always justified not by some far off goal, but by actual user cases, expressed by the users.

Another good reason: Engineering

One client approached me with an in-progress kitchen sink app. I talked to him for a while and we discussed the engineering team. I could see some flaws in organization- the senior lead didn’t have enough time and energy to devote more full time to the project, and the junior developer had time, but not expertise. The list of features was ambitious, and without a full time senior developer, I could see how decisions were being made, and time spent (billable) in the wrong directions. Spaghetti comes to mind. While he was interested in me working with his lead, it would largely be pointless as he needed to rebuild his product design with his engineering team in mind. Don’t do anything new (the project was daunting enough for a junior dev) stick to common UI objects, keep it simple. Release early and get the lead to build a good iterative testing and analytics framework – that he can do in his short time. See how you can mold the project, a modest, one-feature app, to the team you have? Another great reason to KISS, is accessible resources. Prototypes rarely require that much intense engineering. It’s the business idea that’s the secret sauce, not fancy code and algorithms. Well, unless fancy algorithms is your business idea.