Less Wrong Product Design

Before starting, please consider the following as the general definition Product Design used here:

The comprehensive procedure, encompassing pertinent interactions among all involved parties, tied to the conceptualisation, development, and eventual launch of a (digital) product to its targeted audience.

I recently watched after some time Marty Cagan's 2018 "The Root Causes of Product Failure" talk at Mind the Product San Francisco. Recommended watching.

Regrettably, Cagan's points retain an undeniable relevance in today's landscape, as his depiction of an inherently flawed Product Design process still remains the norm within many contemporary organisations.

In a nutshell

The status quo

The existing, widespread Product Design process is still riddled with significant shortcomings.

You may claim to practice Agile, yet you isolate the Design and Build elements into an Agile subset where all incoming and outgoing communications are carefully screened and selectively managed.

A considerable amount of your time is consumed by resolving Design versus Build conflicts and pacifying the grievances of major stakeholders.

The end result is that you expend an enormous amount of effort on intermediary deliverables, with an all-consuming focus on meeting deadlines and fulfilling the specifications within the Scope of Work.

You may indeed achieve timely delivery within the set budget. But what, exactly, will you have delivered?

The Ideal Path Forward

Involve all parties from the outset during the ideation phase. Make consistent estimations based on prototypes, continuously refine these prototypes, and frequently test what you have rather than what you intended to have.

Moving everything to the beginning of your product design journey implies involving all stakeholders - Business, Design, Product, Development, and Testing - in the same brainstorming setting, commonly referred to as a war room.

Business will likely be the most heavily represented, with other areas typically represented by their respective leaders.

In practical terms, this demands leaders in Design, Technology, Product, and Testing roles who are more than just representatives of their respective domains.

When Technology leaders discuss technology, they should adopt a business-oriented perspective, understanding the market trends and the technological strategies employed by competitors. Design leaders should not only grasp consumer behaviour within the wider market, but also appreciate the broader business implications: the potential impacts of differing customer experiences and the logistics behind policies like "free returns". Product leaders need to establish fundamental rules and dynamics of the product and its integration into the organisational ecosystem, which includes comprehending how a specific technology choice or user experience could impact other overlooked sectors of the organisation. Test leaders should perceive themselves as the custodians of product measurements and testing throughout the project. Their role shouldn't be confined to User Acceptance Tests (UATs) or automated test cases, but should extend to collaborating with Designers to build measurable prototypes, even if these are rudimentary paper-based models created during brainstorming sessions.

Sprints should no longer be seen as external components, operating in isolation with their own set protocols and rites. Instead, they should be considered as successive cycles of the ideation room, where Product, Design, Build, and Test collaborate cohesively, with Business representatives seamlessly weaving in and out as needed.

---

The Dominant Product Design Paradigm

The diagram I am about to outline probably strikes a chord; irrespective of whether you or your organisation has full control over the entire process, it's likely that you can identify the stages preceding and following your typical involvement.

From the perspective of a Strategic Designer, my critique of the above flawed process is fundamentally systemic (I shan't be focusing on the Design step), and while observing events (or symptoms), I would interrogate this model right down to its vision.

I shall not necessarily navigate through the aforementioned process in a sequential top-down manner, just to clarify.

Not Truly Agile

The first observation you might make is that the process is sheer waterfall methodology, and it's not simply due to the indentation and red arrows. It's waterfall, plain and simple.

So why, in spite of this being the procedure you consistently apply, are you persuaded that you're operating within Agile? Here's the explanation.

The current, more or less deliberate, misconception of Agile within organisations is confined to the Design and Build stages; occasionally, only to the Build stage.

The most widespread interpretation of Agile revolves around constraining the Design and Build team into a mechanical relationship defined by sprints and disseminated through rituals and ceremonies.

The inherent inefficiency of this interpretation is embedded in its structure: information must traverse between different models (waterfall/agile).

It's a structural defect that will influence everything else. You are faced with two worlds: one that halts at Requirements and resumes at Testing, operating according to the waterfall modus operandi with all its rules and expectations - and another world, which you label as Agile, with its own set of rules, expectations, and internal dynamics.

Communication between these two realms will be challenging, and you'll expend significant energy and resources in managing handovers, transferring requests - rectifying - re-transferring, controlling stakeholders and the internal dynamics of the Agile subset.

Also, you essentially eliminate any realistic chance of rapidly adjusting your scope to respond to insights or market trends (for instance) - and this is because your Requirements and Testing stages are excluded from the Agile zone.

Incorporating these two components (Requirements and Testing) into the Agile sphere is a step some organisations take. While this may seem substantial, it merely enlarges the Agile zone, allowing for more participants without altering the engagement dynamics of the various teams.

Ultimately, this turns into a (project) management issue, with resources and energy expended on maintaining unity, managing stakeholder expectations and ensuring delivery deadlines, taking precedence over all else - decisions will be influenced by what essentially becomes a Project Management team.

The primary risk (which invariably occurs) of this insular view of Agile is the development of a product that is sculpted by adhering to what has been pre-agreed and solidified into a Roadmap. Somewhere. By someone.

"It's in the roadmap." takes precedence over "We learned we should do this."

The Roadmap - What Is It Exactly?

A prioritised list of features set against a timeline with initiation and deployment dates. The issue with the Roadmap is that it is based on arbitrary assumptions about the product's value (both to the business and the consumer) and the cost of its development (resources, financial outlay).

Arbitrariness of Value and Cost

The product's value may be tentatively calculated based on a hazy understanding of the market opportunity, but its realisation largely hinges on external influences beyond your control (such as consumer trends, introduction of new products) and undisclosed internal factors (like the quality of your design/build process) that determine whether your product delivers value or not.

A similar argument can be made about cost: external factors (such as licensing costs and taxes) and internal circumstances (like the need for new resources) can only be roughly and partially estimated, especially considering that the product's definition has not yet been finalised (spoiler: it never will be).

The common process for deriving effort estimates (Design/Build) for something undefined usually entails working on a backlog of generic features (typical in the context of the industry/target/product type), supported by experiences from previous similar projects. This backlog is likely to remain as your sole definition of the product, with minor adjustments made along the timeline.

The Illusion of Requirements

It may shock some, but merely transposing requirements from word documents into user stories in Jira doesn't magically transform the process into Agile.

Additionally, requirements are now being used as the exact definition of the product. According to this perspective, the product is merely the sum of its features, nothing more, nothing less. The product definition hasn't been shared with Agile teams simply because there isn't a defined product.

Much like scientists in a laboratory, disregarding the external environment, Agile teams engage in their marathon, sprint by sprint, against time - churning out feature after feature, unaware of the overarching product vision.

The features evolve into the product, with the objective now being to deliver features as scheduled in the roadmap, in order to adhere to its timeline.

Exacerbating this scenario, the Product Team now holds the reins - controlling the centre, as chess players would advise. In other words, it filters and translates communication between the idea generators and the implementers, the upper echelons and the frontline.

What's likely to happen is that the Product Team essentially defines the product, not as part of a design exercise at the outset, but by shaping it in accordance with delivery dates and through negotiations with Agile teams on one hand, and the Business on the other.

This opportunistic strategy stems from a misunderstanding: the deliverables (evidence of work as specified in the SoW) or the tool we design (e.g. a mobile app) are seen as the end goal, instead of the outcome (the value expected from the product), which of course is the end goal. This worldview is inevitable given the role the Product Team plays in the above context.

Redefining the Extremes

Setting aside the 'Deploy' phase for a moment (let's consider it a facet of the 'Build' phase -- I am aware this is an oversimplification), we are left with the extremes: Ideas (the origin and development of the product concept), and Test (the validation that the product functions as intended).

The issue with Test should be reasonably apparent: it is too far down the line in the process. It ought to be positioned at the outset; testing a prototype is paramount in determining your product's form. The Test Team should be integrated during the ideation phase. If this seems unusual to you, it's likely because you have been repeatedly fed an inaccurate narrative about testing.

In fact, at its core, the Test Team is fundamentally a data team. Their work revolves around gathering, analysing, and interpreting data throughout the product development lifecycle. This data-driven approach underpins critical decision-making, ensuring that the product not only functions as intended but also aligns with the market needs and the broader organisational strategy.

The Origin of Ideas

Traditionally, the Business and Customers have been the primary fountainheads for product ideas. While these sources can certainly provide valuable insights, it's crucial that the information they offer isn't taken at face value. Instead, such inputs should be seen as a launchpad for exploration and innovation. Their ideas need to be carefully reframed, interpreted and used to ignite discussions that can lead to the creation of truly transformative products.

By reimagining the roles of all teams involved, including the process of generating ideas, organisations can create a more effective and holistic product design process. This process encourages constant collaboration, allows for the timely adjustment of strategies based on real-time data, and ensures that the final product aligns closely with both market needs and organisational goals.

[first published on LinkedIn on July 19th 2023]