How focusing on technology seams keeps projects from unraveling
I am a product manager and a salmon fisherman — both are notoriously maddening but periodically dispense rewards for perseverance, skill, and knowing where to focus your effort. In that vein, I want to share my observations with a concept I call “technology seams”.
How does fishing relate to Product Management you ask? For context, the rivers here in the Pacific Northwest are vast. As a fisherman with so much water to explore you learn to focus your effort on the places where fish are more likely to be. This is often done by looking for so-called “seams” in the water. Seams are areas of transition between fast and slow moving water caused by bends, submerged rocks, and other river features. Fish linger around seams because they appreciate the respite from the relentless current but it also affords them a quick escape to fast-moving water should a predator arrive. I think if it were possible to see one, seams would look like a fluid piece of fabric suspended in an ever-changing liquid that fish interact with via their intuition.
Similarly, Product Managers know that software components such as the design handoffs, data structures, and services endpoints are part of a project, but in this article, I want to draw more deliberate attention to the significance of these transitions that I have come to believe they are critical for project success. So what are they, where do they occur, and why are they important?
Seams
Seams manifest themselves at every significant handoff point between specialized disciplines where there is a change in paradigm or data shape: from design to front-end, from front-end to back-end services, and back-end to the front-end. Each specialty speaks its own language and moves at a different pace. Wherever there are transitions, there is tremendous value in concentrating on the design to ensure an elegant, laminar flow.
I’d like to share the process I employ with full-stack projects that help ensure that technology seams are recognized early and receive the attention they deserve:
- Purpose: Assemble the entire team and get them on the same page by clarifying the core objective, develop a common understanding of what data will be managed and how will it be manipulated.
- Focus: Minimize the noise and anticipate the transitions — plan with a special eye towards where the data handoffs occur and drive the timeline around those milestone events.
- Execute: Organize the workstreams by anticipating bottlenecks, especially anything involving dependencies on external partner teams.
Purpose
It is the responsibility of the product owner to bring the entire tech team together: front-end, back-end, QE, and design resources and articulate the high-level project plan. The objective is for everyone to understand the reason and goals of the project. I have found information architectures, data flows, rough wireframes, some contextual product strategy, and metrics are all pieces of this presentation. Ensuring everyone understands why this is a compelling project helps generate engagement and enthusiasm.
Visual diagrams showing how the project components relate to one another is extremely helpful. In addition, it is advisable that projects be limited to what can be accomplished in three to four sprints — anything that would go beyond that is difficult to process, although the product vision can project well beyond a few sprints and thus provide longer-term continuity.
Focus
With a baseline understanding derived from the high-level project planning meetings, I’ve found spikes allow the different disciplines to sketch out the work they expect is required but also surface clarifying questions before committing to their tasks. I’m a fan of spikes and seem best done in the sprint just prior to when the core development is scheduled to begin thereby ensuring well-organized thinking and thoughtful estimates.
In particular, ensuring that the “seams” are at the crux of discussion at this point. Keep in mind the costs of change are low at this stage so it is the perfect time to dig in and review the use-cases and data flows in detail.
Spikes should result in sufficient clarity that sprint tasks can be defined as necessary to support the project with confidence. Thought too should be given to how to parallelize the effort so as to reduce time to market. For example, allowing work on the high-level UI design to occur alongside back-end design, should allow the development of the back-end services to proceed while final design iterations shake out.
Execution
Now that development is kicked off to a sprint-based cadence, the following activities should be occurring with an eye towards avoiding bottlenecks occurring, especially ones that will occur at the seams.
- User Interface Design— as more detailed wireframes lead to comprehensive designs, new questions can arise that may create new data requirements. My teams have had success with Sketch and Figma as prototyping tools, which facilitate collaboration and conversation between everyone on the team. (And as a bonus, these tools produce assets that can be easily consumed by the front-end developer such as colors, layout, etc. to accelerate the ultimate build.)
- Back-end — the back-end team should document and concisely surface the new services or adjustments to existing services if new endpoints. Since well-constructed services are so critical to future flexibility, it is worth spending some time discussing the implications of the changes so as to ensure that you’re not painting yourself into a corner.
- Quality Engineering must be engaged and starting to develop test plans, optimally with automation in mind. Since services generally need to be completed first, their workflow likely begins with the back-end followed by the front-end.
Managing Technology Seams
Separate from standups, I have found bringing the full team together twice-weekly (~30 min) is very helpful to ensure that questions arising on either side of a seam can be effectively surfaced and optimally resolved.
Examples of seam-centric milestones to plan for include:
- Data requirement definition — Front-end developers should have enough clarity in the project to begin laying out and loosely assembling the parts to identify oversights in the service design while they are waiting for the designs to be finalized.
- Early Services— while front-end can get rolling with mock data, the sooner mock services can be stood up by the back-end team, the sooner “seam” issues can be identified and addressed. Postman is an extremely effective tool for exercising and presenting proposed interfaces to a larger audience, but nothing beats front-end hitting a real service.
- Crystalized Services— once the services are stood up, data representative of production should be connected to the front-end as soon as possible. This especially helps with the non-happy path cases. All too often the happy path cases do not consider real data and those unexpected events often cause serious schedule disruption.
In summary, product management/product owners must pay special attention to each interface seam and aspire to resolve misunderstandings and eliminate miscommunications as quickly as possible— doing so will help ensure core project success. So like with fishing, I believe focusing on transitions will increase the likelihood of success. This approach demands you have a deep appreciation of numerous disciplines, but I strongly believe that recognizing seams is the mark of both a seasoned product manager and it should help you be more effective at fishing, so good luck wherever you cast!
