Platform is the paradigm
When a large company transforms to a platform-based infrastructure, the intent is to ship 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 offered by a platform-driven approach can set up a business for success, but without good, old-fashioned human communication, there’s arguably more potential for complexity 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 who’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
Why the platform product manager role is 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 the different pieces. 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 happens, it’s important to have people with particular skills act as the connective tissue between 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 manager, who tends to be educated in computer science or engineering and very focused on technical matters.
PPMs act as a pivot between executives and the traditional hyper-user-focused product managers and they help manage across the business from stakeholders to user experience (UX) designers to developers. PPMs cast their vision both tactically for immediate needs and long-term in the roadmap for users.
In a large organisation that is already so complex that it needs platform transformation, it’s useful to differentiate the PPM and PM so that the latter doesn’t get pulled too much in any one direction among technical considerations, business needs and user needs. That way, nobody gets stretched too thinly in the difficult process of evolution.
Within the business, PPMs must see in both directions: inform executive planning by pushing upwards what the PMs know about users and jobs to be solved and, at the same time, 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 critical for collective understanding
Many customers we interact with won’t have traditional PMs and UX experts. Therefore, our design and – by extension – development teams will be receiving 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.
So, how can the PM – the prime mover and gravitational centre of a product, feature or initiative – prevent lapses, gaps and errors? Once we get down to the execution level, we have to be extra careful to keep the dynamic and complex in order 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. This has likely arisen from the hyper-pressure to ship and the way that ideas frequently become more extreme when they make that mysterious cultural move from sound principle 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 of which features get built and why require even more diligence and attention in the platform model because their visibility and access are better. Duty and deliberateness are heightened, and those get tended to with 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, adaptive and fast-moving to businesses 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 and 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 to prevent problematically incomplete work from 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 or feature, needs to be strong, clear and articulate… and document hypotheses in the form of sufficient product requirements.
- 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, but the consequence of abused principles dressed up as agile often is that nothing, or almost nothing, gets documented. It happens all the time when teams are trying to respond to the pressure to deliver more quickly. Preventable mistakes slip through, things that require time to go back and clean up later.
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. For instance, an excessively scaled-back interpretation of what constitutes an MVP (minimum viable product) can be forced on a group by time and pressure. And post-shipping, more cycles of examination, meeting and revision will be needed.
When ‘agile’ becomes ‘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 can be applied to an existing set of (flexible) design decisions rather than starting over 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, since 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 say 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 upfront 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 from ways of working results in incompletely thought-out product ideas and imprecise design. Even in a healthily working 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 ago, or two, or three? 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 will degrade with the inevitable dissolution of memory. A quick check of an abstract, a use case, a wireframe or 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 specifications, tactical details of how something is supposed to work or 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 of only 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 – guaranteed. Writing things down helps 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 aren’t 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.
Rumour has it that Jeff Bezos used to require PMs to express product concepts in a simple paragraph of text, not as a slide deck. Boiling ideas down to their essence is the first test of their value. If it can’t be communicated in concise, plain language, then there’s a problem. This prevents hand-waviness and the 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 waterfall to have some ordering to these events, but it’s really some upfront 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 collective 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 through 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.
5 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 you 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 you only need to write as much as will achieve a collective understanding and general assent among the business, product, UX and engineering teams on intent, function and direction.
3. Organise the product documentation along agile principles. Think of theme, initiative, epic and 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 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 from different perspectives. 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 with indeterminacy. At some level, product and UX work is about committing to unknowns, and oracles are hard to find. Have a map to guide your direction, data to support hypotheses and break down intent and initiatives into measurable, tactical and 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.