Is it a product, an experiment, or a demo? Let me explain with a brief anecdote…
Recently a routine project status meeting (snoozer, right?) rapidly escalated into a contentious spat, with accusations flying about â€œlack of supportâ€ and â€œnot valuing the results”. Whoa! Stepping back from the unexpectedly flared tempers I asked the Dev and PM leads a simple question: â€œSo what exactly are we building here?â€ Because it had become sorely apparent there was a crucial, unstated misunderstanding which had led to this moment of tension. Ascertaining what exactly weâ€™re building (and thus, for which purpose) would clarify practical concerns and prepare the team for what needs to be done next. Unfortunately, this project had been running along on so many parallel tracks with missed chances for clear communications, due to false assumptions all along. Whew.
But I digress. So, what exactly were we building? And what are the implications for each option? Seems there were three basic paths overlapping yet at odds with each other:
a) A product: This implies building a fully-formed, self-sufficient entity with proper data, networking, API hooks all set up for actual usage by a particular customer for achieving certain tasks. Thereâ€™s a resolved & integrated sense of brand, features, utility, and style that feels complete and ready for public release. The goal here is delivering a wholly formed object or service of tangible value for business gain, and customer satisfaction!
b) An experiment: Following popular â€œstart-upâ€ and â€œleanâ€ thinking, this implies creating something that is narrowly scoped, based upon an hypothesis, to help achieve proper product-market fit downstream. The goal here is minimizing risk, maximizing learning, and doing so with efficiency. The audience is limited, with clear expectations set about what to expect. Usually itâ€™s a rough prototype of limited capability, with parts not functioning or simply hinting at future utility, as prompts for user feedback. And the expectation here is that it could all totally fail, as any experiment!
c) A demo: The reality for enterprise software is that there is a structured sales pipeline and customer engagement practice including wooing market analysts and vendors via exclusive previews or demos of whatâ€™s next. And yes…sometimes you have to design for the demo, to tell a certain kind of story that addressees marketing or sales goals. Demos can be simply â€œsmoke and mirrorsâ€ or more robustly defined, but regardless, are tuned for a highly calibrated messaging purpose to stoke customer interest (although not necessarily feedback).Â
It should be apparent that each path involves a different approach to resourcing and leveraging the design process accordingly. A product is a full-blown, complex, multi-party coordinated effort with critical dependencies spanning divisions. You need a fully coordinated design team effort, from concept to delivery, with every potential bug closed or gap sealed. An experiment is far more scoped down and thus forgiving with direct impacts on specific engineering and design needsâ€”in the words of Herb Simon, â€œdo whatâ€™s necessary yet sufficientâ€ to be expedient. And a demo is a wholly different affair, with closer coordination with marketing and sales strategy members, that can be a tightly limited, even isolated, exercise, with zero impact on real engineering. The application and distribution of resources can vary, and itâ€™s important to note the differences, as they impact the use of designers & researchers too.
(You could certainly serve multiple purposes, but itâ€™s sensible to have a main target to strive towards, to keep everyone focused. Anything incidentally supported becomes a secondary benefit, thatâ€™s welcomed but not a distraction. That expectation must be firmly conveyed!)
Getting back to my situation, those accusations of â€œlack of supportâ€ or â€œlack of interestâ€ in the results, well…they were suitably corrected by clarifying what we need to support for, and what kind of results weâ€™re all expecting to strive for. While a sparkling demo is important to impress future customers, a diligently fleshed out product for customer usage is arguably more valuable with significant efforts needed to enable market success. Understanding this difference can help a team ascertain their true goal and set proper expectations, across the board for everyone.