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.