Specifying The Product

Last time I wrote about the digital product, the output of the digital factory. Together with breaking the work up, we have a broad picture of how the work happens, and how it fits into a project. Let's recap. Product takes business goals and synthesises them with a social context to form a plan. This plan is high-level, and turning the plan into tasks that can be completed by developers requires some work. So far I have glossed over this process, but I was reasonably specific about how well estimation often turns out.

Let's take a step back to talk about how the tasks come to be, before they are estimated.

The product concepts are transformed into outcomes that the product should facilitate - requirements. How this happens specifically depends very much on the makeup of the project team and for economic reasons there is a spectrum of configurations. I have been in situations where I have worn nearly every hat simultaneously, meaning that I have been the product person and the designer and the developer and a project manager. I have been in other situations, with various other combinations of those roles. How roles are assigned is some function of the nature of the project (i.e. its anticipated requirements and its budget), the natural alignments of organisations involved in the project and the team itself - the experiences of individuals and the relationships between members.

The mapping of high-level requirements to deliverables in practice often has a number of baked-in restrictions / limitations:

• The tasks should be completable within a short period of time, e.g. two weeks. This can have a material effect on the alignment between the work that is done and the objectives that drive the work, at least in the short-term.
• At least in part due to divisions of labour and contentions for resource, mapping of requirements to tasks may not have direct involvement from the whole team, which leaves the door open for an altering of the deal downstream when new requirements emerge.
• As mentioned in the post introducing the digital product, there is a dynamic social context, which may reshape the planned deliverables, which has an indirect but hopefully nevertheless obvious knock-on effect on the value and priority of prescribed tasks, another path to altering the deal.
• There are often precision gaps. This happens when specified behaviour could be achieved in a myriad of ways, and it often turns out that many of these ways may be unacceptable for one reason or another (e.g. presentation, cost, speed, and so on).

Unfortunately between all these concerns there is a lot of opportunity for "process theatre", where everyone is following an agreed-upon protocol that emerges from some set of practical considerations, but no one is getting what they want or need out of the process.

The process around gathering requirements itself emerged in response to a real problem. Humans generally think and speak in relatively high-level terms, to a much greater extent than we have the opportunity to understand in much of everyday life. The process of gathering requirements aims to reduce the number of iterations between an expression of want, and the delivery of products to service that want, which is naturally large.

In the zeitgeist there is a palpable sense among professionals with an interest in software that it is important to deliver faster than ever before, and people often look to new technologies, or innovations with pre-existing technologies for solutions. I believe delivering fast is as much about process and people as it is about technology. Here are my thoughts on process:

• Know what you need - this should be as small as possible.
• Know what you want - this information can shape trade-offs, in code there are many different kinds of good.
• Lastly, know what can happen when working with digital systems - this can avoid waste.
  • Online services may be unavailable, partially available, or fully available. This status may also change at any moment.
• A file system may be at 100% capacity.
• Users may deny requests for permissions, an instance of access rights.
• There is a digital supply chain, a division of labour, and a field of truth. The universal experience is an illusion.

Until next time.