More Tenets For Effective Product Management
Replicate (Don't Reinvent) Great UX Patterns
Build a UX pattern library: Whenever you encounter exceptional user experiences, document them systematically. Create a personal repository of screenshots, screen recordings, and bookmarks organized by interaction type. The most successful digital products aren't reinventing UX—they're thoughtfully applying established patterns.
Why this works:
- Users develop mental models from tools they already use.
- Familiar interfaces reduce cognitive load and learning curves.
- Established patterns have already been market-tested at scale.
- Your engineering team can focus on implementation rather than invention.
The best products combine familiar interaction models with unique value propositions. Slack didn't reinvent messaging—it applied proven patterns from consumer apps to workplace communication while solving key integration problems.
Implementation tip: Create a "UX inspiration" Figma board or shared folder where your team can contribute examples of excellent solutions to specific interaction challenges (e.g., "Great onboarding flows" or "Effective data visualization"). When discussing features with engineers, reference these real-world examples rather than abstract descriptions. This creates a shared visual vocabulary that accelerates development and reduces misunderstandings.
Don't Commingle Backlogs
Each product deserves its own dedicated backlog with a clear owner and execution team. Without this separation, effective prioritization is impossible. This applies to anything that qualifies as a "product"—whether it's independently priced and sold as a subscription, branded as a distinct offering, or positioned as part of a broader product line.
I once inherited a chaotic backlog containing thousands of tickets spanning five distinct products within the same line. The "execution team" was an entire department of 50+ people in various engineering roles with a single Scrum Master. Predictably, this role had seen three PMs resign after very short tenures (3-12 month) before me. In order to get things back on track, I created four separate JIRA projects (five including the original) -one for each product -distinct backlogs, and organized the formation of autonomous cross-functional execution teams. Gradually, as we demonstrated increased velocity on previously stalled initiatives, and as budget permitted, I hired an Associate PO for each team.
Failing to implement this separation inevitably leads to a predictable outcome: only urgent issues and requests championed by the loudest or most influential stakeholders receive attention... much to the detriment of more important strategic initiatives. The key is insulating each product's roadmap and execution path from stakeholders who naturally advocate only for their specific interests.
This separation serves a critical resource allocation function as well. When multiple products share a single execution team, resource gaps become obscured. For instance, if Team Alpha lacks a Data Engineer, it becomes immediately apparent why Product Alpha can't progress on new ingest pipelines. Contrast this with a scenario where Products Alpha, Beta, and Gamma share resources—suddenly the failure to advance Product Alpha gets misdiagnosed as poor prioritization rather than the actual resource deficiency. What appears to be an unmotivated or underperforming team is actually a structural resourcing problem that separate teams would have made obvious.
Prioritize Function Over Design in Your Application
Design has its place in websites, branding, and marketing collateral—but should be minimized in your core application. At too many companies, marketing or brand departments insist that all applications strictly adhere to corporate style guides that change every 6-12 months. This creates an endless cycle of non-value-adding design tweaks that divert engineering resources from what matters.
When your frontend team spends 90% of their time pushing pixels and tweaking CSS, they're not:
- Developing features that deliver tangible user value.
- Improving core user experiences that drive retention.
- Writing tests that ensure application stability.
- Optimizing performance that keeps users engaged.
Companies that move fastest on their product roadmap separate application functionality from design perfectionism. Google's early spartan interfaces and Amazon's utilitarian design allowed them to iterate rapidly while competitors got stuck in design cycles.
Practical approach: Include your product logo, maintain basic visual consistency, and embrace off-the-shelf component libraries your engineers prefer (Material UI, Bootstrap, Tailwind, etc.). When design decisions arise, ask: "Will this design change measurably improve user outcomes, or is it just aesthetic preference?"
Remain Outcome-Oriented
This is more nuanced and requires more practice than you’d think. As a simple example, if I write the following user story:
As an admin user of the Product Alpha organization management screen who has just performed [insert task name], I want to click on a button so that blah blah blah.
I’m inadvertently specifying an interface affordance (via “click on a button”) rather than an outcome (e.g., "save my changes"). By doing so, I’m putting unintended limitations on the technical implementation; in other words, I’m not relying on the talent and intuition of my frontend engineers (in this example). This is a mistake because if you hire incredibly talented engineers (which you should, read more here), you want them to have the flexibility and autonomy to implement the best technical solution. You’re probably thinking, “what about the wireframes”? Time permitting, I create wires for everything that requires user interaction. And yes, I use buttons, filters, tables, icons, and everything else that you’d expect. BUT, the purpose of my wireframes is to convey functionality—they are a visual supplement to my user stories—rather than acceptance criteria or functional requirements.
That said, there are strategic exceptions where direct involvement makes sense. When implementation is faster than documentation—and you possess the technical skill—rolling up your sleeves might be the most efficient path. Similarly, if you can make a meaningful contribution, such as developing a proof-of-concept that visually demonstrates a complex script's intended outcome, your hands-on work accelerates understanding. In cases where you haven't yet defined clear success criteria, conducting initial exploration yourself can derisk the project and establish valuable guardrails. Finally, when implementation requires navigating complex dependencies between application components or third-party integrations, your specialized knowledge may necessitate more prescriptive guidance to ensure system integrity.
Hire Frontend Engineers with User-Centered Design Instincts
Finding engineers who inherently understand user experience creates a multiplicative effect on product development velocity. The ideal candidates possess both technical expertise and an intuitive grasp of what makes interfaces delightful to use.
Look for these indicators during hiring:
- Entrepreneurial background or side-project portfolio showing end-to-end product development
- Interest in user behavior and ability to articulate why certain interfaces work better than others
- Experience working directly with users or customers in previous roles
- Comfort with ambiguity and willingness to prototype rapidly before committing to implementation
- Demonstrated ability to simplify complex workflows into intuitive interfaces
Engineers with these traits can make independent UX decisions during implementation that align with user needs—often better than specialists working from abstract requirements. This capability is especially valuable in early-stage products where speed of iteration trumps pixel-perfect design.
Real impact: Teams with UX-minded engineers can compress the entire design-build-test cycle, sometimes eliminating entire steps in the process. A single conversation about user goals can directly translate to working code, bypassing extensive wireframing and design review sessions that slow momentum.
For startups or new product initiatives, this approach can reduce time-to-market by weeks or months while maintaining high-quality user experiences.
Photo by Dan Schiumarini on Unsplash