Platform Meets Product

As companies transform to the platform paradigm, how does product management adapt and remain effective?

Next Gen Insights | Graeme Fordyce |
13 August 2019

PLATFORM IS THE PARADIGM

When a large company transforms to a platform-based infrastructure, the intent is shipping more product to a growing user base more quickly and with higher quality. Of course, organisational theory in and of itself can’t magically affect that set of outcomes from the top. A streamlined chart of people and processes looks great and is meant to make sense of complexity, but what is happening with products on the ground needs to be running effectively.

The broader platform model is predicated on independent systems that can more easily share data, components, and experiences so that the technical framework can be used to build multiple products. If the business is scaling and more product is shipping more frequently, there’s likely more interrelated content, functionality, and customer interaction to understand from a high level.

The flexibility on offer from a platform-driven approach can set up a business for success, but without good old-fashioned human communication, there’s arguably more potential for complexification in the system as initiatives are tried, as products proliferate and grow. At both the strategic and tactical levels, some due-diligence aspects of product management can help keep chaos at bay. Getting the help of a large, established technology partner that’s familiar with the ins and outs of the platform play can help companies organise thoughtful, streamlined processes, and avoid a lot of the grind of transforming.

ONE ROLE TO BRING THEM ALL

The role of a Platform Product Manager and why it’s a good idea

One seduction of acting like a tech company is that things will start to move really quickly. It’s all very exciting and we’re shipping and adding value and there’s no time to produce and pore over reams of documentation. And it’s hard to take a moment to look at all of the different pieces and collect them into shape. Not doing so, however, exposes the company to risk because problems will proliferate in at least a direct relationship to expanding interdependencies and relationships between products on the platform.

When this is happening, it’s important to have people with particular skillsets there to act as the connective tissue among teams and streams. These are the Platform Product Managers (PPMs), customer-centric, technically-sound thinkers dutybound to understand the wide-ranging relationships and interdependencies created by a platform-based organisation. This is a somewhat different animal than a Platform Manger, who tends to be CS/Engineering-educated and very focused on technical matters.

PPMs are there as a pivot between executives and the traditional hyper-user-focused Product Managers and help manage across the business from stakeholders to UXers to developers. PPMs cast their vision both tactically for immediate needs and long-term in the roadmap for users. In a large organisation that already has the complexity of needing platform transformation, it’s useful to differentiate the PPM and PM so that the latter doesn’t get pulled too much in one direction among technical considerations, business needs, and user needs, and also so that nobody simply gets stretched too thinly in the difficult process of evolution.

Within the business they must see in both directions: inform executive planning by pushing upwards what the PMs know about users and jobs-to-be-solved, and simultaneously make sense of the shared content and functionality available so that PMs can maximise the potential of the platform in service of the customer base. This is a role that can prioritise work based on platform strengths and capabilities and help collect apparently disparate business initiatives into shape for maximum design/development efficiency and brand effect.

AMIABLE HERESY – AGILE PRACTICE AND THE PM

Documentation is a good thing; writing things down is critical to build collective understanding.

Many clients we interact with won’t have traditional PMs and UXers, and as a consequence our design teams and by extension dev teams will be intaking work requests with less-than-optimal detail, guidance, and justification. Too often, well-intentioned, smart, motivated cross-functional teams don’t manage to communicate effectively. How does the PM, the prime mover and gravitational centre of a product/feature/initiative, prevent lapses, gaps, and errors? Once we get down to the executional level, we have to be extra careful to keep order to the dynamic and complex in a scaling platform environment.

“- I’d like to get some use cases written up prior to UX launching into the designs, spec out how the features are supposed to work…

- Specifications are kind of old-world thinking. We’re working in agile.”

In this context, agile is the word on the tip of everyone’s tongue. Agile is deservedly the dominant paradigm, but like any popular idea, is prone to stereotyping. The relentless cadence of working in agile requires terrific discipline and structure but ironically the term is often deployed to avoid process and documentation. This might sound a little like waterfall territory, but it’s more a reaction to a common over-rotation into a more caricatural version of agile that seems to have arisen from the hyper-pressure to ship and the way that ideas frequently extremify when they make that mysterious cultural move from sound principles into dogma.

Platform transformations don’t work magically by themselves—they lend the potential for improving aspects of work and workflow for organisations and people. The details, what features actually get built and why, require even more diligence and attention in the platform model because visibility and access are actually better. Duty and deliberateness are heightened, and those are attended to by solid product management principles that often get left behind by pat and facile interpretations of agile. Even in the start-up space, which feels innovative and adaptive and fast-moving to businesses that are emerging from a more traditional operating model, it’s a frequent pitfall. As a general principle, when one part of the business is clarified, simplified, streamlined into logical services, the alignment and fluidity of communication among those groups has to follow suit.

For the tech and business sides to move together quickly and effectively and prevent problematically incomplete work slipping through to the consumer, there must be a requisite understanding of how vision and tactics align around a consumer need. There must be enough detail on record to make sure that a project is initialised adequately and has real substance rather than only a sense of direction. There’s a great, old-fashioned way to achieve this – writing things down. This is where the PM, the ‘CEO’ of the product/feature, needs to be strong, clear, and articulate… and document hypotheses (in the form of sufficient product requirements) from cloud to fish level.

“- There are lots of UX bugs that need to be addressed…

- We’re going for an MVP, so we’ll have to fix them later. We need to be agile.”

Nobody wants to drown in documentation. A thousand clam-level use-cases will drive anyone crazy. But the consequence of abused principles dressed up as agile often results in nothing, or almost nothing, getting documented. It happens all the time when teams are trying to respond to the pressure to deliver move quickly. Preventable mistakes get through, things that require time to go back and clean up later, from the flying-by-the-seat-of-your-pants mentality. The obvious counter is that the agile model accounts for and responds to this pain, which is true. But situations where people are scrambling for definition far too close to the end of the sprint happen all too often, and, for instance, an excessively scaled-back interpretation of what constitutes an MVP can be forced on a group by time and pressure. And post-ship, more cycles of examination, meeting, and revision need to occur.

When “Agile” become “Ad hoc” it’s no longer the methodology in play, even if people keep saying the right words. Design as a system is a great example. A UX team needs to hypothesise a little more, ahead of time, so that iterative cycles appeal to an existing set of (flexible) design decisions rather than being built for the first time again and again. Of course, perfection isn’t the goal in any given release; it’s asymptotic by nature. But there’s a lot at stake, even when shipping seemingly small things. Users have plenty of competitive options.

The agile stereotype is seductive in its ease and apparent clarity to fall back into like a comfortable chair. It's a relaxing idea. Less is more. Things work themselves out if we collaborate and iterate. It's the swirling intensity of the tech life. We do what it takes to get it done, right? It’s all about code! Agile is meant to be less linear and hierarchical, and more circulatory and cooperative. And that’s a wonderful thing as long as perception doesn’t get to a point where anything that seems at all prescriptive is suspect. Agile, used as a buzzword, is one that people speak when it’s convenient (I don’t have time to spec this feature) and ignore when it’s not (The devs already built this feature and don’t want to change it now). Rapidly ideate and test… fail fast. What does fast mean? If a little up-front work can minimise the risk of failure and reduce walk-backs, why accelerate towards doom at a greater rate than necessary?

Removing sequence or linearity to ways of working results in incompletely thought-out product ideas and imprecise design. Even in a healthily firing agile team, there’s a place for an initial declamation of an idea, an estimation of its concrete value, a description of the planned interactions between system and user. These hypotheses, when recorded and defined initially, let designers attack a problem in the language of interaction and layout with much more lucidity. A clear set of design artefacts lets developers speed up their coding and understand the function and value of what they’re building.

“- I think we need to add some annotations to the wires so the devs have a better sense of how this will work…

- We’re being agile, so let’s just cover it live in stand-up.”

Agile isn’t meant to eliminate documentation – it just reduces it to the requisite information to inform designers and developers about what to do. What happens if nobody records any ideas? How well can we expect to remember the justifications that made sense a month or two or three ago? As products gain complexity, how can we expect to go back and revise ideas that don't exist accountably anywhere?

It’s a balancing act – a team can’t slog through reams of minutiae, but if all the intent, functional detail, and interactions are only conveyed verbally, the likelihood of successful implementation begins to degrade immediately with the inevitable dissolution of memory. A quick check of an abstract, a use case, a wireframe, a style guide, will save much more time and effort than reconvening a group to go over the facts of the case repeatedly.

FURTHER DEFENCE OF DOCUMENTATION

Why it’s useful to think and write rather than only think.

It’s a very common issue that product teams and PMs don’t take the time to write formal or informal use cases prior to launching into the UX and build phases of a project. Cursory user stories, a title field in Jira, or even verbal delivery of intent are often meant to suffice. The diligence of writing down specs, tactical details of how something is supposed to work, interactions between user and system, is a way of making the nebulous concrete, a mechanism for interrogating one’s own assumptions, biases and ideas. When designers are wireframing on the basis only of one or two group conversations, trouble lies ahead. When developers are coding based on wireframes that are based on group conversations, we’re going to be revisiting the feature prior to launch, dollars to donuts. Writing things down helps a group respond to change, because the reason for a feature and its intended functionality is right there, clear as day, ready to be revised or overturned.

Lofty concepts and whiteboard sketches simply are not enough. The act of writing is a crucible for ideas, a gate to pass. If ideas aren’t diligently articulated to a sufficient level of detail, designers and developers can end up trying to create tangible interfaces from fuzzy, consensus-driven thought. Apocryphally at least, Bezos used to require that PMs express product concepts in a simple paragraph of text… not in deck form. Boiling ideas down to their essence is the first test of their intrinsic value. If it can’t be communicated in concise, plain language, then there’s a problem. This prevents hand-waviness, prevents the natural charisma of a speaker from influencing the room more than the idea itself. Writing closes the gaps that are often filled by charm, confidence, groupthink, hope, and even desperation.

The due diligence of product ideation and management is critical to narrowing the gap between what’s envisioned and what actually gets built. It might sound a little like waterfall to have some ordering to these events, but it’s really just some up-front time investment that makes more development happen faster as products inevitably grow and morph. There will be plenty of opportunity for collaboration; silos need not form. Change will always happen and how a team reacts to it is a test of their dedication to the agile methodology. Write down just enough to avoid human foibles. It’s motivating for engineers to know why they’re building what they’re building; it’s motivating for the group, an extra alchemical element, to rally around a collected understanding of the product.

In a platform environment where different services, all moving quickly, have to understand their relationship to each other, clarity will pay back much more than the time it took to harden the ideas with requisite documentation. Agile, performed by rigorous PMs at the outset, is a satisfying way of working that generally leads to better products in more users’ hands, added business value, and happier, motivated teams.

Five tips for strong PMing and solid documentation:

1. Remain customer-obsessed at all times. This doesn’t mean you can forget about the business, but rather that you focus on the customer’s goals in the context of typical tasks and mindsets, then work with the PPM to connect and effect the goals of the business.

2. Always be specting, questioning and challenging Start with a template for writing use cases. Alistair Cockburn’s approach is tried and tested. Remember that one need write only as much as will achieve a collective understanding and general assent among the business, Product, UX, and Engineering on intent, function, and direction.

3. Organise the product documentation along Agile principles: Theme, initiative, epic, user story/use case. This helps the PM prove what higher-level company themes are being met by more granular everyday work.

4. Collaborate/Elaborate. Share the spec documentation with all stakeholders for vetting and group clarity. A use case, a design element, a piece of code, and a consumer’s experiential moment are all the same thing viewed through different sides of a prism. If it doesn’t make sense to someone in the working group, there might be an issue to address before it’s out in the wild.

5. Get comfortable (and try to make those around you comfortable) with indeterminacy. At some level Product and UX are about committing to unknowns, and oracles are hard to find. Have a map to guide direction, data to support hypotheses, and break down intent and initiatives into measurable, tactical, executable pieces. A PM with their head-in-the-clouds will run into trouble, so stay focused on consumer reactions and KPIs. The fun (and responsibility!) really begins post-shipping.

Graeme Fordyce

VP Product/UX

Drawing on experience in diverse fields including search, payments, e-commerce and SEM, Graeme has been hands-on with all things product related since the late 1990s. He works with our clients to simplify the complex and drive effective product thinking with an emphasis on tactical execution and consumer empathy. Before joining Endava, Graeme spent time working with both high-tech start-ups and world-renowned brands. When he isn’t thinking about all the ways to improve products, Graeme enjoys chess, rugby, and landscape photography.

All Categories

From This Author

10 April 2020

The Four Pillars of Truly Digitised Organisations – Part 2
03 April 2020

The Four Pillars of Truly Digitised Organisations – Part 1