Category: Agile & DevOps

Congratulations, you’ve landed a product management role on a technical team building software, apps, or hardware. But now comes the tough part: learning enough about the technology to collaborate effectively with engineers.

Acquiring fluency in “Techlish” can seem daunting, especially if you don’t have a technical background. However, with the right strategies, resources, and mindset shifts, you can bridge the knowledge gap.

Let’s explore five concrete ways to bootstrap your technical PM expertise:

Leverage online training resources

Numerous websites like Coursera, edX, Udemy, and Udacity offer beginner-friendly training on software engineering concepts. Structured courses and tutorials teach you key terminology, fundamentals, and core principles across domains like:

• Programming languages like Python, JavaScript, Java
• Web development skills (HTML, CSS, React, Angular)
• Cloud infrastructure (AWS, Azure, Google Cloud)
• Data science and analytics
• Mobile app development

Don’t try digesting everything at once or it will be overwhelming. Focus your learning selectively on the specific languages, frameworks, databases, and infrastructure your product relies on. Look for courses that provide hands-on labs and projects to accelerate practical skills.

Dive deep into documentation

Your own product’s documentation is a technical goldmine. Developers have to create specs, architecture diagrams, admin guides, API references, and other collateral.

Treat this documentation like required reading:

• Note acronyms and definitions you’re unfamiliar with and compile a glossary
• Study architecture diagrams to understand high-level components and data flows
• Review API documentation to grasp how services communicate
• Read release notes to learn about new technical features and fixes

Documentation reveals how all the technological pieces fit together. Refer back to it regularly to fill knowledge gaps. Don’t just skim—take detailed notes.

Find a technical mentor

Learning complex technology in a silo can be slow and confusing. A faster approach is finding an internal mentor.

Look for an experienced architect or lead engineer who:

• Enjoys teaching and explaining technical concepts
• Has the patience for lots of questions
• Believes PMs should understand the technology stack

Schedule regular “Tech 101” meetings to explain concepts, review architectures, dig into roadmaps, and translate acronyms. This human shortcut helps you ramp up faster via 1:1 knowledge sharing. And, as a side benefit, your mentor can also give you insider insight into how the team is operating, where the product is in the best shape, and where it needs the most attention. 

Understand how engineers make decisions

Beyond technical jargon, you need insight into how engineers evaluate options and make build vs. buy vs. wait choices:

• What factors do they consider when selecting frameworks and tools?
• How do they quantify and prioritize technical debt?
• What metrics and benchmarks guide performance optimization?

Understanding their decision process, not just the syntax they use, enables you to have intelligent discussions. Learn what types of technical arguments resonate with them. And, perhaps most importantly for a PM, how to translate their domain knowledge into “Businessese” so you can effectively advocate for your product team when talking to leadership.

Shift your mindset

Finally, evolving your mental models and attitudes is crucial for effective collaboration:

• Be proactively curious—ask “why” and “how” frequently
• Remember you’re on the same team, working toward shared goals
• Value engineers’ specialized expertise that complements your skills
• Check ego and don’t pretend you know more than you do
• Have patience and accept you won’t become an expert overnight

Adopting an authentic, team-first mindset makes technical workers far more likely to invest time in your growth. Let humility and curiosity shine.

Becoming “technical” takes time and focus

There are no shortcuts to gaining true technology fluency. Be patient with yourself. The payoff of increased credibility and tighter collaboration with engineers is worth the effort.

Use these tips to supplement hands-on learning:

• Take online courses focused on your tech stack
• Treat documentation like a textbook
• Find internal mentors happy to explain concepts
• Observe engineers making decisions
• Shift your mindset from ego to curiosity

Level up your technical product management skills, and you’ll be equipped to make products customers love.

As an Agile Coach, one of the most common questions that new Agile teams ask me is: “What metrics do we need to track?” So, I’ll share what I tell them.

But, before we dive into the details about the metrics themselves, I think it’s worthwhile to consider the reasons that most teams are expected to track and report metrics. 

Why are we obsessed with metrics?

Here are a few of my observations from my experience working on various types of projects:

1. Senior management / leadership is accustomed to seeing metrics. In the traditional project management world, most organizations that follow the waterfall/plan-driven approach seem to gravitate towards the standard RAG (Red/Amber/Green) project health status. I’m not sure where this system came about, but it may be tied to tools such as Microsoft Project. 
2. Team leaders (or managers) generally are too busy to be directly engaged in the details of an Agile team, and need data to help them understand the current state of the project so that they can communicate the status upwards to their leaders and project sponsors.
3. The members of the Agile team need data to help them manage their work so that they can determine if they are on-track or need to ask for help.

While all of these are valid and understandable reasons to implement metrics, there are many dangerous pitfalls that teams can encounter when attempting to do so. 

Strategies for deploying metrics

Here are a few suggestions that may help new Agile teams deploy metrics effectively.

Start simple

Don’t try to implement 20 metrics immediately, even if they sound simple. From my experience, there is usually a higher-than-expected cost associated with each and every metric your team chooses to deploy, and they can slowly strip away valuable time from your team and their ability to focus on doing “real work”. 

My recommendation: start with no more than three metrics that can be tracked using the Agile management tool you are already using. Most industry-standard tools such as Azure DevOps or Atlassian Jira offer reports and some type of data analytics within the tool itself, so the start-up cost should be relatively low.

Don’t share it without explaining it 

Once your team starts tracking metrics, there will be a temptation to publish the data broadly to everyone and anyone within your organization. As a result, some reports may be shared unintentionally or without forethought. This may be a risky time for your team especially if your organization is not accustomed to the metrics your team is using (i.e. velocity, throughput, etc.), which means they could be misinterpreted by someone important but not close enough to the work to make sense of this data. 

My advice: prepare your team and help them to explain the data to whomever may have access to it. Learn to craft a message around the data to provide context, and help the target audience understand the “why” behind the data.

Connect to business objectives and value 

As a continuation of the previous point, explaining the “why” behind the data will be even more powerful if your team can connect the data to the business goals of your organization. 

For example, if your metric shows that your team is completing 90% of planned work on average for each sprint, your team is performing at a very high level and is helping the overall organization deliver consistent value to the customers and stakeholders. Be sure to make that connection to the business outcome, because the number in itself (90%) is meaningless without proper context.

Review and adjust regularly 

As your team matures, you will likely want to modify your metrics strategy, which may seem like a lot of work. Encourage the team to think about how they are doing and explore ways to adapt. The organizational objectives will likely change throughout the year, so it is vital for the team to stay in tune with those changes and evolve accordingly. For example, if quality is becoming an area of focus, it may make sense to start tracking defect rate.

Automate where possible 

As the team continues to apply more metrics, it will make sense to deploy automation where possible to reduce the ongoing overhead of managing the metrics and the data. 

Some possible solutions to consider include plug-ins for your Agile management tool or creating some simple scripts to automate the data collection process.

Final thoughts

To wrap up, if your team has not spent much time thinking about metrics yet, it may be a good time to start now before your leaders impose something that may not make sense for your product. If you take the initiative and begin tracking and publishing meaningful data associated with your team, you will help your team share successes and challenges and begin building trust with the sponsors and stakeholders. In time, this will help build a collaborative environment that leads to successful outcomes for your project.

“We aren’t estimating stories accurately.”

“Our velocity is inconsistent because we can’t estimate well.”

If your team is making comments like this, you may be tempted to focus on estimation skills. 

But often, the real issue is upstream: your backlog isn’t framed and refined properly to enable estimation.

In this post, we’ll walk through how to build a value-focused backlog for technical products using discovery practices like story mapping. With well-defined stories tied to customer needs, your team can estimate and deliver value reliably.

Let’s get started.

Much of this article is derived from our comprehensive guide, The Non-technical Product Manager’s Guide to Technical Product Management. Read it here.

Backlogs blocked by poor discovery

Imagine your leadership dropped a major initiative in your lap:

Build an automated drone analytics platform for commercial site inspections.

Now you need to produce a prioritized backlog for your developers to estimate and execute on. Where do you start?

Most PMs are taught to decompose requirements in a linear way:

But this top-down approach leads to abstract stories disconnected from specific value.
Without customer context, engineers struggle to estimate size accurately.

That’s why mature PMs know discovery comes before backlog definition. Discovery practices like:

• Customer interviews
• Story mapping
• Impact mapping

These help you frame the backlog around concrete value vs. nebulous requirements.

Let’s see how story mapping can build a value-focused backlog using our drone analytics example.

Step 1: Map the end-to-end process

Start by visually mapping out the end-to-end workflow for users. This establishes the big picture before diving into granular stories.

For our drone analytics platform, key steps include:

• Set up and configure drones
• Capture aerial footage during site inspection
• Process and analyze footage via AI
• Generate inspection reports for clients

Focus on the critical use cases and steps users move through to accomplish their goal. The backlog will bring this workflow to life incrementally.

Step 2: Capture capabilities as rows

Next, break down that workflow into distinct capabilities that support each step. Capture epics or features as rows on your map.

Example capabilities for drone analytics:

• Automated drone flight plans
• Computer vision analysis of aerial data
• Annotated inspection report creation
• Role-based access controls
• API for third-party data integration

Resist detailing requirements. Just capture capabilities needed to enable the end-to-end workflow.

Step 3: Define value with columns

Now move down the first capability and ask “How does this deliver incremental value?” Define 3-5 columns showing increasing value from left to right.

For automated flight plans, columns could be:

• Manually define flight grids
• Generate flight grids from 2D site maps
• Optimize dynamic flight path around 3D site model

Doing this exercise for every capability clarifies how functionality builds on itself to drive user value.

Step 4: Identify MVP with your team

With the full map in place, gather input from stakeholders on what capabilities and value increments are absolutely essential for an MVP.

In our example, the core workflows of capturing footage and generating reports are likely critical. Advanced functionality like APIs and access controls may wait.

This input helps you identify the thin vertical slice through the map that becomes your MVP backbone.

Step 5: Break down columns into granular stories

Your prioritized MVP path through the map provides framing to detail out stories within each capability.

Take the MVP column for automated flight plans: “Generate flight grids from 2D site maps”. 

To enable estimation, we need to define granular stories like:

• Upload 2D site map in supported formats
• Validate site map dimensions and parameters
• Automatically generate waypoints for efficient flight grid
• Display flight grid overlay on map for user approval
• Save flight plan for importing to drone modules

Small, testable stories like these allow developers to size work accurately.

With the end-to-end map plus detailed stories in place, you now have an actionable backlog framed around delivering value, not just capabilities.

Real-world examples of discovery for technical products

While story mapping is extremely effective, there are other discovery techniques PMs can use to build technical backlogs:

Impact mapping

Impact mapping is ideal when you know the business outcome but not how to achieve it. Start by defining the goal, then drill down into capabilities and stories.

For a chatbot to improve customer satisfaction, an impact map might surface conversation workflows and natural language processing as key enablers.

Technical spikes

Sometimes you need to research solutions before defining stories. Create timeboxed “spikes” for things like:

• Evaluating algorithms for image processing
• Proving a new cloud service will meet scalability needs

Let findings inform your backlog.

No matter what, start with discovery

The next time you’re struggling to build a vague backlog or size nebulous stories, remember that estimation begins with discovery. Well-defined stories tied to customer value enable accurate estimation.

So before your team tries to estimate better, invest time upfront to:

• Map the end-to-end workflow
• Identify key capabilities
• Map columns showing increasing value
• Break down MVP features into granular stories

This discovery work pays dividends by resulting in a backlog built to drive value delivery.

Dive deeper by downloading our comprehensive guide, The Non-technical Product Manager’s Guide to Technical Product Management.

Struggling with misalignment and disjointed teams? This quick guide teaches you how to set Objectives and Key Results (OKRs) to boost engagement around shared goals, a method used by Google, Netflix, and other successful organizations. 

Learn how to write inspiring objectives, set measurable key results, master OKR cycles, and avoid common pitfalls. Follow these OKR best practices to rally your teams, create focus, and drive results.

Why we need to know how to set OKRs

Workplace alignment is broken. A staggering 95% of employees don’t understand their company’s goals, according to Gallup. No wonder performance suffers – only 35% of US staff feel engaged at work.

But what if there was a way to rally your teams around shared objectives that really move the needle for your business? A goal-setting approach that boosts clarity, focus, and results?

Enter OKRs – Objectives and Key Results.

This simple yet powerful framework is used by elite companies including Google, Spotify, and Intel to engage employees and accelerate growth.

OKRs distill an organization’s priorities into concrete goals that inspire teams and enable data-driven execution. They promote transparency around progress and outcomes. The result: better collaboration, agility, and measurable results on objectives that matter most.

With clear focus and shared purpose, OKRs unlock discretionary effort and peak performance from your people.

Understanding OKRs

OKRs are a goal-setting framework used to drive engagement, accountability, and results. With clear objectives and measurable key results, OKRs keep everyone aligned to top business priorities and focused on outcomes that really matter.

At its core, OKRs have two components:

1. Objectives: These are significant, concrete, and inspiring goals that reflect an organization’s top priorities. For example, an objective could be “Increase customer retention by 15%.”
2. Key Results: These are measurable steps to achieving the objective. Key results act as milestones to track progress. For the sample objective above, key results could be:

• Reduce customer churn rate to less than 5%
• Launch VIP loyalty program for top customers
• Increase Net Promoter Score to over 70

With engaging objectives and rigorous key results, OKRs create clarity, transparency, and urgency throughout an organization. Employees understand how their work ladders up to big goals. Leaders get an aggregated view of progress toward strategic outcomes.

And with regular check-ins on OKRs, teams adapt quickly when circumstances change. Resources get allocated dynamically to the most important objectives. In this way, OKRs drive organizational agility and performance.

Crafting rock-solid OKRs is critical to realizing these benefits. But it takes skill and discipline to develop objectives and key results that get results. 

How to write strong objectives

The keystone of any OKR framework is the objective. This sets the direction and rallying cry for your teams. Well-crafted objectives have four key attributes:

1. Significance – The objective should connect to a vital company goal and strategy. Ask yourself “If achieved, how will this objective create significant value for our business?” Significant objectives inspire teams to bring their A-game.
2. Concreteness – Vague objectives lead to confusion and poor execution. Use specific, unambiguous language. For example, “Increase revenue from new product line by $2 million” is far superior to “Grow new product revenue.”
3. Action-orientation – Verbs drive action. Use active voice and strong verbs like improve, expand, reduce. “Improve product uptime to 99.95%” pushes teams more than “High product reliability.”
4. Inspiring – Objectives should energize and mobilize teams. Use vivid and positive language. Consider how achieving the objective impacts customers and business. Paint that picture.

Here are some examples of rock-solid objectives:

• Increase customer lifetime value by 20% in 12 months
• Reduce customer wait times by 50% in 6 months
• Launch AI chatbot and reduce support calls by 30% by Q4

Well-crafted objectives set a clear, actionable course for your teams. They focus efforts on outcomes that deliver disproportionate value. The result is engaged, motivated teams and accelerated progress on your most important goals.

Learn how to build optimal OKRs using GTMHub.

Best practices for OKR cycles

To sustain momentum and impact with OKRs, disciplined goal cycles are critical. Here are some proven techniques:

• Cadence – Set OKRs on a quarterly or biannual schedule. Quarterly allows for urgency while biannual reduces burden. Google uses quarterly OKR cycles to maintain focus amid rapid growth.
• Goal-setting meetings – Hold collaborative meetings at the start of each cycle to define objectives and key results. Ensure involvement from executives to individual contributors to drive engagement. For example, Netflix holds company-wide goal-setting workshops.
• Progress Monitoring – Check in on OKR progress at least monthly, if not more often. Schedule regular updates on key results through team huddles or one-on-one meetings. Some teams hold weekly OKR progress reviews.
• Agility – In dynamic environments, business needs can change quickly. Provide a mechanism to modify or add OKRs mid-cycle if needed. For example, attaching dates to key results allows adjustments.
• Retrospectives – After each cycle, hold retrospectives to discuss achievement, gaps, and learnings. Analyze why some OKRs were met while others were missed. Identify process improvements. Feed insights into planning the next cycle’s objectives and key results.

Benefits of OKR cadence:

• Maintains consistency – OKRs remain top of mind.
• Creates urgency – Frequent sprints drive progress.
• Enables transparency – Regular updates increase visibility.
• Allows agility – Flexibility to adapt to changing needs.
• Drives improvement – Continual refinement over time.

In summary, disciplined OKR cycles promote sustained alignment, accountability, and results quarter after quarter.

Common OKR mistakes to avoid

Even seasoned OKR practitioners make missteps now and then. By learning from others’ mistakes, you can craft an effective OKR program from the start. Here are some of the most common pitfalls to avoid:

• Not getting buy-in – Without broad buy-in, OKRs won’t take hold across your organization. Avoid just handing down goals from the top without input from below. Make sure all levels fully participate in co-creating objectives and key results.
• Setting too many OKRs – Resist the urge to establish too many goals. This creates confusion and diluted focus. Keep it simple – limit your organization to 3-5 objectives per quarter. And cap key results at 3-5 per objective.
• Lacking transparency – Don’t hide OKRs in obscurity. Ensure every employee can see top-level company OKRs. Make OKR tracking visual and public through shared dashboards. Transparency drives accountability and engagement.
• No regular reviews – Don’t “set and forget” your OKRs. Schedule regular check-ins to review progress. Adapt goals if business conditions change. And hold quarterly retrospectives to identify improvements for the next cycle.

By dodging these missteps, you set your OKR program up for success from day one. Take the time upfront to build skills in objective-setting, progress tracking, and open communication. 

Making OKRs work starts with laying the right foundation

With clearly defined objectives and key results, teams stay aligned and motivated around your most important goals. Tracking progress and outcomes provides focus and accountability. Regular OKR cycles promote agility to drive sustained execution.

But successful OKR implementation takes work. It requires executive buy-in, consistent diligence around progress updates, and a culture of transparency. By following the best practices outlined here, you can get your OKR program off the ground successfully.

With the techniques covered in this guide, you can start crafting impactful objectives and key results for your organization.

Well-designed OKRs will help you:

• Align your teams around shared goals
• Increase transparency on progress and outcomes
• Boost employee engagement and motivation
• Accelerate growth through laser focus
• Rapidly adapt to changing business conditions

Don’t let competitors leap ahead. Start leveraging the OKR framework today to engage your people and outperform rivals. The first step is setting meaningful OKRs that move your organization forward.

Achieving product excellence and delivering value quickly and consistently can be difficult at enterprise scale. Organizations adopting the SAFe® framework often encounter challenges that can hinder their agility and throughput. As a Product Owner, Product Manager, or Release Train Engineer (RTE) in an enterprise, understanding these challenges and their solutions is crucial for optimizing flow and achieving strategic objectives. 

This article delves into six common challenges and offers actionable solutions to enhance your scaled agile efforts.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile Inc.

Challenge 1: Lack of visibility into the full book of work

The Problem

One of the first hurdles in scaling a product-led approach is gaining a comprehensive view of all the work that teams are engaged in. This lack of visibility can lead to misaligned priorities, missed deadlines, and inefficient resource allocation. Moreover, when you can’t see the full scope of work, it becomes difficult to make informed decisions, leading to a reactive rather than proactive approach to problem-solving.

The Solution

The key is to utilize Program Increment (PI) planning effectively. During PI planning, create a program board that serves as a “single pane of glass,” displaying all commitments, milestones, and dependencies. This not only helps in aligning the teams but also in identifying any bottlenecks. A well-maintained program board can be a powerful tool for facilitating communication and collaboration among teams, thereby enhancing overall productivity.

Challenge 2: Aligning work with strategic goals

The Problem

Teams often lose sight of how their work contributes to the organization’s strategic objectives, leading to a lack of focus and diluted impact. This misalignment can result in wasted efforts and resources, as teams may work on tasks that don’t significantly move the needle in terms of strategic goals.

The Solution

Establish a visual representation that maps the work items to strategic goals. This ensures that everyone understands the “why” behind the “what,” reinforcing the alignment between daily tasks and long-term objectives. By making this alignment explicit, you can ensure that every team member is aware of the bigger picture, thereby fostering a culture of strategic thinking and focus.

Challenge 3: Unclear understanding of ART velocity

The Problem

Without a clear understanding of the Agile Release Train (ART) velocity, it’s challenging to gauge what can be realistically achieved in a given Program Increment (PI). This lack of clarity can lead to overcommitment, resulting in stress, burnout, and ultimately, failed objectives.

The Solution

Calculate the ART velocity by aggregating the velocities of all the teams involved. This provides a tangible metric that aids in prioritization and work-in-progress limits. Understanding your ART velocity allows for more accurate forecasting, helping you set achievable goals and manage stakeholder expectations effectively.

Challenge 4: Lack of visibility into dependencies and risks

The Problem

In large setups, dependencies and risks often go unnoticed or are poorly managed, leading to delays and inefficiencies. When dependencies are not clearly identified and managed, they can become blockers that stall progress across multiple teams.

The Solution

Visualize and manage dependencies and risks in a central repository. This enables teams to identify bottlenecks and act proactively. By having a centralized place to manage these elements, you can ensure that nothing falls through the cracks, allowing for smoother execution and delivery.

Challenge 5: Constant need to update and maintain roadmaps

The Problem

Keeping stakeholders updated with accurate and current roadmaps is a constant challenge. Outdated or incorrect roadmaps can lead to misaligned expectations, causing friction between teams and stakeholders.

The Solution

Ensure that all work items have estimated start and end dates. This allows for the automatic generation of roadmaps, keeping everyone informed and aligned. By maintaining up-to-date roadmaps, you can facilitate better communication and trust among all parties involved, making it easier to navigate changes and adapt as needed.

Challenge 6: Limited availability of customizable reporting

The Problem

Standard reporting often falls short in providing the insights needed for effective decision-making. One-size-fits-all reports can lack the nuance and detail required to fully understand the complexities of your specific enterprise environment.

The Solution

Extend your data and create custom visualizations to meet your specific reporting needs. Custom reports allow you to focus on the metrics that matter most to your organization, providing the insights needed to make informed decisions and drive continuous improvement.

Applying these lessons

Understanding and addressing these six challenges are critical steps in optimizing your journey toward scaled product excellence. While this article provides a comprehensive overview, there’s always more to learn. 

To gain deeper insights and actionable strategies, we highly recommend watching the full webinar, Six Challenges RTEs Face and How to Solve Them, available on-demand. In addition to an expanded treatment of what you’ve read above, you’ll also see an onscreen demo of a software tool that can aid you in applying everything you’ve learned. 

Feel empowered to take action and elevate your enterprise’s journey to the next level.

When building a software product, you’re really constructing an iceberg.

The glossy UI with all the buttons and menus makes up the tip visible above the water. But beneath the surface lies a massive foundation of code, services, databases, APIs and infrastructure.

While customers only see the tip, the entire iceberg impacts their experience. As a PM, you have to manage the whole product.

In this post, we’ll cover tips for integrating above- and below-the-surface work to ensure your iceberg ships smoothly.

Remember: technical debt impacts customers

With an app or website, it’s easy to obsess over pixel-perfect designs and forget about technical debt piling up downstairs. But neglected architecture and infrastructure absolutely affect what users experience.

Symptoms of excessive technical debt include degraded performance, frequent outages, and scalability limits. These directly hurt customer satisfaction. Refactoring may not be glamorous, but it improves the product.

So when prioritizing features versus technical work, evaluate expected business impact before making a final decision:

• Will addressing debt reduce loading times and improve conversion?
• Will upgrading our storage improve reliability and retention?
• Will focusing more on what’s below-the-surface make those new features shine even brighter?

Run both types of work through the same product discovery process and planning rigor. Make trade-offs based on customer value, not perceived sexiness.

Validating non-functional requirements

Traditionally, teams focused on validating “non-functional” requirements like performance and security just before launch. But it’s risky to wait until the end of each release cycle to test things like:

• Site speed and scalability
• Accessibility compliance
• Authentication protections

It invites last minute crunches.

The better approach is to evaluate these abilities continuously alongside feature work. For example:

• Establish performance benchmarks, and test against them with each sprint deployment.
• Build accessibility testing into your QA automation suites.
• Conduct security audits mid-way through release cycles.

This way, you catch issues immediately and can course correct versus playing catch-up late in the game.

Tips for integrating surface and subsurface work

So how can product managers actually integrate above and below surface work into delivery cadences? 

Here are some proven tips:

Promote “technical user stories”

User stories are a great way to capture small work items tied to value. Make sure to write them for technical tasks too:

• “As an API developer, I need request throttling to prevent abuse.”
• “As a site admin, I need dashboard alerts for high memory usage.”

This frames infrastructure work on equal footing with feature work.

Reserve capacity for unplanned issues

When planning sprints, assume unexpected technical work will arise and leave buffer room:

• Pad estimates on complex stories
• Keep some stories uncommitted as contingency
• Define slack time for firefighting and debt pay down

You’ll need flexibility to handle subsurface iceberg chipping without blowing up the top.

Prioritize architectural initiatives

Epics and themes that enable architectural evolution should be prioritized and resourced:

• Breaking up the monolith
• Migrating to microservices
• Decoupling tightly coupled components

Don’t let the urgency of surface features derail major subsurface improvements.

Enforce definition of done

Expand “definition of done” beyond feature requirements to include non-functional aspects like:

• Meeting performance benchmarks
• Passing security scans
• Updating documentation
• Executing integration tests

This ensures quality and architectural integrity.

The bottom line

Customers ultimately care about outcomes, not the underlying technology delivering those outcomes. But as PMs, we have to obsess over the entire product.

Managing the subsurface architecture and infrastructure is just as critical as the visible UI. By integrating the above and below work, you’ll launch technically sound products that customers love.

So don’t just manage the tip of the iceberg! Plan for the massive part hidden below the surface at all times.

In the world of technical product management, you need to master a diverse set of capabilities. From understanding code to pitching executives, effective PMs have to toggle between technical details and high-level strategy daily.

But aside from core skills like communication and prioritization, what practical tips help PMs deliver technical products in the real world?

In this post, we’ll cover five tactics for navigating common technical PM challenges including:

• Selling refactoring work
• Managing engineers without coding expertise
• Speeding up development velocity
• Staying in touch with what matters to the customer

Master these practical tricks of the trade to step up your technical product management game.

Tip #1: Sell refactoring by highlighting value

Here’s a familiar scenario: your engineers want to pause feature development for a few months to pay down technical debt. This refactoring work will improve stability and enable long-term velocity. But your executives want to see exciting new capabilities first and foremost.

How do you sell mandatory refactoring in this situation?

First, avoid leading with tech jargon like “technical debt” and “refactoring” in the boardroom. Those terms are meaningless to non-technical leaders. Instead, quantify the business value impact in their language:

• “By rebuilding our messy legacy code now, we can accelerate releases by 15% next quarter.”
• “This infrastructure upgrade will reduce service outages by 30%, improving customer retention.”

Second, frame large refactoring projects as enablers of critical business outcomes:

• “Re-architecting our monolith platform is required to launch our mobile apps with the needed performance.”
• “Migrating to microservices is essential for entering the Asian market and achieving our growth goals.”

In other words, paint a clear line between refactoring and tangible business results. Technical debt may not be sexy, but investing now enables outcomes they want tomorrow, which is.

Tip #2: Call out B.S. (without being a developer)

Even without a development background, you’ll need to challenge engineering assumptions and call out B.S. occasionally. So how do you effectively push back on technical experts?

First, get smart on the basics of the codebase and architecture. Learn enough to understand the fundamentals and ask intelligent questions. Lean on architects willing to teach.

Next, find your “translator”—an engineer willing to advise you honestly when things sound fishy. Develop trust with them to validate gut feelings that something is off.

Finally, focus on collaboration, not confrontation. Say, “I want to make sure I understand the risks here fully so I can support you.” Rather than accusing them directly, use ignorance to extract the truth politely.

You don’t need to be a coder to push back on engineers. Build foundational knowledge, find internal allies, and lead with curiosity.

Tip #3: Learn enough tech details to manage well

We’ve established you don’t need to be a coder. But how much time should PMs spend digging into the technical details?

As a rule of thumb, strive to understand:

• The overall architecture and infrastructure
• How major components and services interact
• Key quality attributes like scalability, security, and performance

Avoid getting dragged into minor implementation details or trying to micromanage. But major architectural decisions, technical trade-offs, and infrastructure choices should be on your radar.

Knowing the high-level landscape helps you make better product decisions and have meaningful technical discussions. Shooting for the “30,000-foot view” is a good goal.

Tip #3: Fix velocity by improving discovery

Slow project velocity plagues many technical teams. But often, the root cause is poor discovery upfront, not dev team capacity.

Flawed discovery leads to inflated stories that are confusing to estimate and impossible to complete. If your team struggles to meet its sprint commitments, ask yourself:

• Are large requirements being decomposed into small, testable stories?
• Do developers understand the user value behind each item?
• Is the backlog ordered to deliver value incrementally?

Improving your discovery practices, like story mapping and MVP definition, is the fastest way to speed up development. Right-sized, value-centric stories enable accurate estimation and rapid iteration.

Tip #5: Build a feedback loop with customers

This last tip is more mindset than actionable tactic. But savvy PMs continually connect customers back to technical decisions.

Building a tight feedback loop helps in two ways:

1. Informs architectural choices. If your customers care most about mobile performance, that data point guides infrastructure decisions.
2. Sells technical improvements internally. If you hear customers complaining about speed, you can sell an optimization sprint.

Constantly gathering feedback is key. Share insights from support tickets, user interviews, and reviews to spotlight technical areas that need attention.

Help engineers deliver value

Technical product management comes with its own unique challenges. But equipping yourself with practical tips and tricks enables you to streamline processes, sell critical work, and collaborate effectively.

Try out these five techniques next time you run into roadblocks on your technical PM journey:

• Highlight business value to sell refactoring
• Learn enough tech to call out B.S.
• Fix underlying discovery before velocity
• Understand the 30,000-foot view of the architectural landscape
• Use customer feedback to guide technical decisions

Mastering these practical skills helps you empower engineers to build products that customers love.

As companies increasingly see the value of pursuing product agility over project management, the role of a Product Owner has gained significant prominence. A Product Owner serves as the customer’s advocate—the ultimate champion of value delivered—and helps coordinate between the product teams, steering the product’s vision and driving its success. While hiring external candidates with Product Owner expertise is an option, many organizations fail to train or develop their internal employees as new product owners.

We will explore some steps organizations can take to identify existing employees that have the right mindset & institutional knowledge, and equip them with the skills required to become effective Product Owners.

Identifying potential candidates

The first step in developing a strong pipeline of Product Owners is to identify employees who possess the necessary skills and mindset. Look for individuals who demonstrate a deep understanding of the organization’s products, show strong communication and collaboration skills, and possess a customer-centric mindset. 

Where to find potential new product owners

These individuals may come from diverse backgrounds, such as project management, business analysis, or software development. But there are some less obvious choices that are often overlooked: 

Call Center and or Customer Support teams are a great place to find potential new Product Owners. The people in these roles speak with your customers all day every day, and hear firsthand what they love and what they would like to see improved. They should have deep knowledge of your products that can translate well to the Product Owner role. 

Marketing roles are very similar in their product knowledge, with an added view into the market landscape and industry trends. 

Another overlooked role are your QA testers. They review changes to your products to ensure they meet the user needs and are intuitive to use.

Core skills these candidates must possess

Here are some core skills to look for:

• Strategic Thinking: Product Owners must have a strategic mindset and the ability to think long-term. They should be able to define a clear vision for the product and develop a roadmap to achieve the desired goals.
• Communication: Strong communication skills are essential for Product Owners to convey their ideas effectively and collaborate with various stakeholders, including engineers, designers, marketers, and executives. They should be able to articulate the product vision, gather requirements, and facilitate cross-functional teamwork.
• Leadership: Product Owners need to lead without direct authority. They should inspire and motivate their teams, provide clear direction, and make decisions that align with the overall product strategy. Effective leadership helps drive the team towards success.
• Problem solving: Product Owners encounter complex problems regularly and must be skilled at breaking them down into smaller, manageable parts. They should be proactive in finding solutions and evaluating potential risks and trade-offs.
• Adaptability: The product management landscape is dynamic, and great Product Owners can adapt to changes quickly. They should be open to feedback, iterate on their approaches, and embrace new methodologies and technologies.

Providing comprehensive training for new Product Owners

Once potential candidates have been identified, it is crucial to provide them with comprehensive training tailored to the role of a Product Owner. The training should cover a range of topics, including agile methodologies, product management principles, user research techniques, and stakeholder management. Interactive workshops, seminars, and online courses can be utilized to impart knowledge and build practical skills.

Focus on enhancing key skills

Here is a list of five skills a good Product Owner should build:

• Market and user understanding: Understanding the market landscape and the needs of the users is crucial for Product Owners. They should conduct market research, analyze user feedback, and stay up-to-date with industry trends to make informed decisions.
• Analytical skills: Product Owners must be comfortable working with data and making data-driven decisions to determine value & opportunity. They should be able to analyze metrics, conduct A/B tests, and interpret user behavior to gain insights and drive product improvements.
• Prioritization & time management: With numerous competing priorities, Product Owners must excel at prioritization. They should identify the most impactful features or initiatives, allocate resources effectively, and manage timelines to ensure timely delivery.
• Technical understanding: While not always required, having a solid understanding of the underlying technologies and development processes can be advantageous. It helps in effective collaboration with the engineering team and in making informed technical decisions.
• User experience (UX) knowledge: Product Owners should have a good understanding of UX principles and be able to advocate for a great user experience. They should work closely with UX designers to ensure the product meets user needs and is intuitive to use.

For examples of Product Owner training and certification options available, refer to our training catalog and search for “Product Owner”.

Coaching and mentoring opportunities

To supplement formal training, organizations should provide coaching and mentorship to aspiring Product Owners via coaches that specialize in product development. Product Agility Coaches are an excellent resource that can draw from their real world experience to guide the new Product Owners in their new daily activities.

Another way to help aspiring or new Product Owners is to provide shadowing opportunities. Seasoned Product Owners within the company can serve as mentors, offering guidance, company specific experiences, and providing valuable feedback. Additionally, allowing aspiring Product Owners to shadow experienced professionals during product development cycles can provide hands-on learning experiences and foster a deeper understanding of the role’s responsibilities.

Cross-functional exposure

Product Owners need to collaborate effectively with various departments within an organization. Therefore, it is beneficial to expose aspiring Product Owners to cross-functional teams and diverse projects. Encourage rotations to different departments, such as marketing, design, engineering, and customer support. This exposure will enhance their understanding of different perspectives and enable them to make more informed decisions when defining product roadmaps.

It is important to continue this communication and collaboration with these other departments. It should not only be something that prepares them for the role. Maintaining strong lines of communication with these groups will enhance the Product Owner’s broader understanding of their product’s needs.

Encouraging continuous learning

Learning should not stop after the initial training phase. Organizations should promote a culture of continuous learning and improvement among their Product Owners. Encourage them to attend conferences, participate in industry events, join professional networks, and pursue relevant certifications. Additionally, establishing internal communities of practice or knowledge-sharing platforms can facilitate ongoing learning and collaboration among Product Owners.

Performance evaluation criteria

Regular performance evaluations should be conducted to assess the progress and development of aspiring Product Owners. Objective criteria, such as the ability to deliver successful products, stakeholder satisfaction, and effective collaboration with the development team, can be used to measure their performance. Recognize and reward achievements while providing constructive feedback for improvement. Additionally, organizations should create growth opportunities for Product Owners, such as advancement to senior roles or involvement in strategic initiatives.

Conclusion

Training internal employees to become new Product Owners: 

• Unlocks the potential of talented individuals within an organization
• Fosters a culture of innovation and collaboration
• Nurtures a strong pipeline of skilled Product Owners
• Ensures a deep understanding of the company’s products
• Drives innovation
• Reduces the overhead associated with external recruitment
• Strengthens employee retention and loyalty 

By providing a clear pathway for career advancement and professional growth, organizations can cultivate a culture of internal talent development and create a competitive advantage in the market.