Leading Product Edition 6
Leading Product Edition 6
LP is Back | Wrangling Requirements | Planning Interfaces | Idioms | Design Thinking Everywhere | The 2030 PM | Contemplation = 9.5 minutes
đȘ Back
After a prolonged hiatus, LP is back.
Edition 6 looks at requirements elicitation, interface design, idioms, an article that drills into the âmicrofoundationsâ of design thinking and innovation, and link to an upcoming event of interest. Letâs go.
𧶠Wrangling Requirements
Where do your requirements come from? Where do they go?
Have you ever been caught off-guard, just before or just after a release, when someone - maybe an internal stakeholder, maybe an end user - points out that something is missing in your solution? âMissing? How can that be missing? We didnât know about it.â In order for requirements to become development mandates, you must be aware of them. And that isnât trivial.
This happens a lot, usually as a result of some kind of review by a security assessor, compliance, or through quality assurance (if the test cases exist). Typically, itâs the nontechnical stuff that can trip up a release if not accounted for during development. And often these are the kinds of requirements that defy prioritization: they tend to be critical (think regulatory) and therefore mandatory to launch.
How does this situation arise? In mature firms, requirements - especially the non-functional kind - might be explicit and well cataloged. Though chances are that as a PM, you will spend some time eliciting requirements, regardless of company size. Doing so is an art and science, and a skill required for the PM-as-diplomat (and interpreter). Letâs dig into how a PM might earnestly search out and meet requirements that wonât always be explicit.
Requirements elicitation obtains systems requirements from stakeholders and other sources and refines them. Both researchers and practitioners consider it one of the most challenging parts of requirements engineering. Numerous techniques (surveys, creativity workshops, and so on) help express requirements precisely and unambiguously.
Socialize the roadmap
Donât wait for launch to have the roadshow - showcase the roadmap across as many different stakeholder groups as possible. Get it in front of everyone, early and often. This can be far easier in a small or young firm. It gets exponentially harder as the firm grows and responsibilities are devolved. Have the roadmap somewhere that people can easily access, and be notified as it changes. Colleagues will put it in context for their area, and that will spark the kinds of conversations that start with âHave you thought of x or talked with y?â I have nowâŠ
Engage the champions
A model increasingly practiced is to identify champions on a given team to act as a bridge between a key area (security, compliance, etc.) and development. Often itâs an experienced developer who can context switch and ensure that knowledge transfer occurs. Call upon this person during epic and sprint planning - âif we had compliance in the room, what would they say about this feature, or this integration.â Champions are in the best position to run demos of the product back to the sponsoring team, and that reinforces the link between them. DevSecOps!
Template
Requirements can have many dimensions: they might include thresholds, specifications, configurations, and so on. The more they can be standardized, the easier it will be to translate requirements into user stories and develop. For requirements to be unambiguous, they must be completely defined. Templates can be taken one step further and turned into reference architectures and patterns, thus allowing teams to scale quickly while pushing updates to a single, authoritative place (code base).
Plan for drift
Over time, elements of the product will fall outside of accepted bounds based on changing requirements. The PM must not only account for new features and functionality, but go back over existing code and integrations to ensure that the entire product remains compliant.
This is related to but different from technical debt (it might be a category thereof) but the solution is likely to be the same: refactoring, swapping out libraries and components, or rebuilding some part of the stack altogether. Either way, it must be planned for and deliberately tackled.
Let the platform do it
Yes, someone owns the platform, too. But if youâre leading the development of a service that has the good fortune to leverage a platform then chances are some of the requirements you would otherwise mandate have been accounted for, especially integrations. (At Dyson, the fan team doesnât care about the filter or need to design one. The filter team provides specs to all supported teams, who ensure compatibility with a shared component. But donât base next yearâs fan off last yearâs filter specs, until youâve checked).
This is when a platform strategy truly pays off: in a firm with a growing product portfolio, capabilities can be scaled by virtue of shared architectures. Itâs usually possible for customers to tell when a solutions provider hasnât leveraged a platform, and they then must invest in stitching together data and processes or will turn to providers who already have.
Requirements met by a platform on which services are deployed reduce the burden on DevOps teams. Itâs not an excuse for them to be wholly unaware, but it does allow for greater focus on a given serviceâs key functionality.
What about validation?
While user acceptance testing, prototyping, and dog fooding (see Idioms below đ) might cover the bases for functional requirements validation, non-functional requirements typically need to be validated by subject matter experts or dedicated tools, like scanners. PMs might need to seek out such checks much like the requirements were elicited: unless itâs a very well defined process (and that must be the goal), itâs up to us to validate and get the green light from governing teams.
Conclusion
These are just a few approaches, of course, and theyâre meant to highlight how PMs reach across organizational boundaries to elicit all possible requirements early on. This might sound a lot like chasing, which is toil, and thatâs probably true. There are second order effects that emerge from these kinds of interactions that are probably valuable but hard to quantify. Still, the firm must make every effort to formalize how requirements are crafted and maintained, and how products ultimately meet them.
Recall that a product has service dimensions, and product leaders must be as deliberate about the service delivery aspects as about features. It doesn't happen automatically. Service dimensions (SLAs! Supportability!) represent requirements with (often) less clear ownership.đ Interface design
Each edition we deep dive on a key skill or term.
A technical PM job posting I came across recently mentions interface design, which is the activity undertaken to build the surface (digital or otherwise) on which users provide input to a system to elicit a result, or output. Interface design is highly iterative and typically starts with identifying elements, sketching, building out wireframes, prototyping, testing, and finalizing. Of course the interface is never really done, and will evolve as product functionality changes.
Todayâs front-end frameworks enable elegant and dynamic interfaces like never before. Still, there are timeless approaches to ensuring that interfaces make it easy for the user to do what they want, i.e. get an output, and look great at the same time. A good interface will not make up for product shortcomings, but the pain of a bad interface will be felt immediately.
This is a huge topic that deserves many more pixels, but Iâll leave it there for now.
More reading
đ±ïž A fun take on Gmail UIâŠ
â Atlassianâs Design System
đȘ Idioms
Found online x 2.
Using backstories and examples, Karina Chow introduces readers to five terms used in (mostly) software development. Itâs a good tech etymology primer. I share it despite being weary of language when used for gatekeeping, something fellow PM Cy calls out here. Still, the idioms are useful to know and prompt a reflection on how a simple term can reflect a complex process. And yet, jargon tends to limit our understanding of important points and undermine trust. So IDK.
đ€ Design Thinking Everywhere
Found in scholarship⊠breaking down the dense stuff :)
The power of design thinking lies in framing opportunities, and thatâs essential to innovation. Stefano Magistretti, Lorenzo Ardito, and Antonio Messeni Petruzzelli published a meta-analysis to establish the theoretical underpinnings of design thinking. This excellent article calls out Practitioner Points, and those alone are worth a skim.
Design thinking - an approach to frame business problems in user-centric ways through experimentation - is based on three microfoundations: (1) individuals, (2) processes and interactions, and (3) structure. Being cognizant of these âlower level aspectsâ enables a firm or team to apply design thinking, and thus be able to undertake the âsense, seize, and reconfigureâ dynamic capabilities.
âŠMicrofoundations better reveal why certain firms excel in getting ahead, while others fail in today's complex and dynamic economic environment.
I would recommend reading this piece alongside Eduardo Da Silvaâs write up about product thinking, which I covered wayyy back in edition 4. Does product thinking encompass design thinking? Overlap? Separate yet related domains?
đïž Events
A section for event listings⊠probably online
September 22. General Assembly will host product leaders Steven Weddle and Deepika Rudra Murthy to ask and answer âWhat PMâing will be like in 2030â. Itâs a free event - register here.
đŠ Contemplation
Where do you go for requirements? How are they maintained, and who owns them?
â€ïžâđ„ Bye
Thanks for reading. Please comment, share and provide feedback.
Franch et al, Non-functional Requirements in Architectural Decision Making (2014).