The Digital Product

In my last few posts, I unveiled the digital factory, and related it back to something recognisable in the real world - the project - and I've also introduced the role of user experience (or UX) designers in bringing digital factories to life after spending a considerable amount of time speaking to concerns that face software developers. To briefly summarise, software developers make plans for digital production processes, machinery and input materials to facilitate various requirements. User experience designers create facades for the non-autonomous machinery, and facades to distract or communicate to the users while autonomous machinery is performing its work, or has failed in some fashion.

The requirements that underpin the production processes, the input materials, the machinery and their facades come from somewhere. Where do they come from? They come from a product team. The requirements are emergent from a social context, which may include, among other things, assessments of potential competitors, an organisational strategy, and conceptualisations of who their users are and what they're interested in.

The social context is constantly changing, and the plans that product make may change just as often in response to it. I've previously mentioned there is a transformation process, or a layer of abstraction, between code and actual digital experience. With product, there is a transformation process between business goals and a plan for a digital experience.

These plans for the product are generally addressed in a piecemeal fashion in a project, as I mentioned in breaking the work up. There is a chicken and egg situation that often plays out as plans are prioritised, and a time to delivery (which is often incorrect, sometimes by an extremely large margin) is estimated, but the estimate can influence a reprioritisation process. Product staff are generally not strongly attached to particular features - the features are an abstraction or a means to an end to meet other goals. They often do not know for certain, for all but the most commoditised of software, that their requests (if met) will meet their goals, which themselves are often a proxy for the goals of the business that owns the project.

The high-level business goals are mapped to product goals which are mapped to tasks which are finally mapped to solutions (for software developers, this is wholly in digital space). That chain of abstraction doesn't sound too far away from physical product development, or any business process for that matter. This is where our old friends primitives and commoditisation are very important. Every software project with serious differentiation in a market bears some similarity to the Manhattan Project, or the Apollo 11 Mission, where a group of professionals need to form a shared conceptualisation of a new entity. The challenges that the Manhattan Project and the Apollo 11 mission had were in a physical world, a remarkably stable platform. One place where the comparison breaks down is this:

The social context reshapes what the product is, (in other words what the requirements are or should be) much faster than the factory can be built.

The engineers on those projects need not have feared that at any moment, Gravity Version 2 would roll out across the universe, wreaking havoc on all the natural systems that had stabilised around Gravity Version 1.

The rate at which the social context (including technological developments) can change is one of several reasons why the delivery of applications is generally broken up into (allegedly) small increments, to allow projects to pivot toward changes in product direction, which is changing in response to the social context. It is also another challenge to add to the pile for software developers. Using the framework we have built so far, I can explain why relatively quickly.

Engineers are given a directive - their project team is in the business of meeting their customers transport needs. The product staff have made an assessment of the social context, and together with other professionals on the team they have specified a beautiful red bike with the intent to distribute and sell to each and every one of their users, who according to research, have no need to travel more than a few kilometres away from their place of residence. Over a period of weeks to months, project engineers perform research and development, and they eventually come up with production processes, machinery, materials, and source from appropriate vendors where possible so they don't have to build all of this themselves. Unfortunately although there are other bike manufacturers in the world, these manufacturers have developed their own processes, machinery and materials over a period of many years, and keep this information to themselves as a trade secret.

Two weeks later, new user research comes in. Most of the user's travel much further away from home than previous research indicated. Sometimes they travel across the country, and sometimes they travel around the world. We are still committed to meeting the travel needs of our customers. How much time is needed to upgrade the bicycle factory to also accomodate these requirements? Will two weeks be enough?

It is a rock and a hard place scenario, and it is baked-in to the heart of the process of building new digital products. The only way through is a mutual respect.

Until next time.