Author: cprime-admin

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.