Recently, I came across a news about a female manager in the IT industry who left her managerial role and started driving an auto-rickshaw. Her income decreased significantly, but according to her, she is happier and more satisfied than she was in her corporate career.
It made me pause and reflect.
As Product Managers, Project Managers, Product Owners, Scrum Masters, and team leads, stress often becomes a normal part of our jobs. In fact, it becomes so consistent that many of us stop questioning it. We simply accept it as “part of the role.”
A student worries about failing an exam. Similarly, many PMs live with a constant fear of missing deadlines, disappointing stakeholders, or not delivering expected outcomes.
The challenge is that delivery timelines are influenced by countless variables, many of which are outside a PM’s direct control.
At the same time:
Stakeholders expect commitments to be met regardless of changing circumstances.
Teams may not always share the same sense of urgency and can become stuck debating minor details.
Priorities shift constantly.
A feature planned for months suddenly competes with a new idea that appeared in a stakeholder’s mind yesterday.
Expectations increase, but resources, budget, and timelines often remain unchanged.
Individually, these situations seem manageable.
Together, they create an environment of continuous pressure.
The main concern is that we don’t discuss the mental health side of product and project management. We talk about roadmaps, velocity, KPIs, OKRs, Agile frameworks, and delivery dates. We skip the part of anxiety, burnout, self-doubt, workplace stress, or the psychological burden of being accountable for outcomes without having full control over all the variables.
Many organizations promote productivity, but far fewer invest in psychological safety and employee well-being.
Many teams discuss blockers, but very few discuss stress.
Many managers ask for status updates, but not enough ask, “How are you doing?”
Technically the real question is not whether stress exists in product and project management.
The question is:
Have we normalized unhealthy levels of workplace stress and burnout to the point where we no longer recognize them?
I’d love to hear from fellow Product Managers, Project Managers, Product Owners, Scrum Masters, Agile Coaches, and team leads:
What creates the most stress in your role?
Have you ever considered leaving product management or project management because of burnout?
What practices, leadership approaches, or organizational changes have helped reduce stress for you and your team?
How can we create more psychologically safe workplaces for professionals responsible for product delivery and project success?
Looking forward to the discussion.
If this resonates with your experiences or challenges, I’d love to connect and hear your perspective. Feel free to reach out https://tahirshahzad.com/contact/. Let’s continue the conversation and learn from each other.
Modern software teams are rethinking how delivery works.
For years, the Agile Software Development movement shaped the way organizations approach the product development lifecycle. Teams adopted sprint planning, retrospectives, story points, and standups to improve collaboration, structure execution, and create predictable delivery patterns.
On paper, Scrum looks complete.
It provides structure.
It introduces accountability.
It forces alignment between engineering, product, and business.
It creates a shared understanding of delivery.
And honestly, for many teams, Scrum framework is an excellent starting point. But then reality happens.
Sprint after sprint, teams start noticing patterns:
Velocity does not improve consistently
Only 60–70% of sprint work gets completed
QA receives most tickets near the sprint deadline
Developers continue pushing code until the final hours
Urgent requests disrupt sprint commitments
Retrospectives identify the same bottlenecks repeatedly
Eventually, teams enter a strange middle ground.
Sometimes delivery works.
Sometimes it fails.
Sometimes velocity is high.
Sometimes velocity collapses.
And after enough time, instability starts feeling normal. The dangerous part is not failure. The dangerous part is becoming comfortable with unpredictable delivery.
Stakeholders Do Not Care About Scrum
Here is the cold, hard truth: Your stakeholders and customers do not care about your agile purity.
This may sound harsh, but business stakeholders rarely care whether your team uses Scrum, Kanban, SAFe, Waterfall, or a custom hybrid framework.
They care about:
Reliable delivery
Product quality
Faster iteration
Predictable execution
Continuous customer value
Customers care even less. No user has ever renewed a subscription because a team conducted perfect sprint planning. Customers stay because the product continuously improves. That is the real objective of Agile.
Not ceremonies, not sprint rituals, not story points. Continuous value delivery.
The real goal is building a delivery system that supports continuous value creation throughout the product development lifecycle.
Understanding Agile, Scrum, and Kanban
Before discussing transition strategies, it is important to separate these concepts clearly because many teams use them interchangeably.
What Is Agile?
Agile Software Development is a philosophy and mindset focused on iterative delivery, collaboration, adaptability, and continuous improvement.
Agile is not a framework itself. It is a set of principles that encourage teams to respond quickly to change while delivering customer value incrementally.
What Is Scrum?
Scrum is a structured Agile framework.
It introduces:
Fixed-length sprints
Sprint planning
Sprint review
Retrospectives
Defined team roles
Definition of Done
Estimation practices
Velocity tracking
Scrum works particularly well for:
Early-stage Agile adoption
Cross-functional alignment
Teams needing execution discipline
Organizations transitioning from chaos to process
The problem is not Scrum itself. The problem is when Scrum becomes rigid while engineering reality becomes dynamic.
What Is Kanban?
Kanban focuses on continuous flow instead of fixed sprint boundaries.
Instead of asking:
“What can we finish this sprint?”
Kanban asks:
“How can we improve flow efficiency continuously?”
Core principles include:
Visualizing work
Limiting work in progress (WIP)
Continuous delivery
Reducing bottlenecks
Optimizing cycle time
Pull-based execution
Kanban shifts the focus from sprint commitment to delivery flow optimization.
Why Scrum Starts Breaking at Scale
The most common Scrum failure pattern is not bad engineering. It is WIP congestion. Too many parallel tasks create invisible delivery traffic jams.
Example:
Developer A starts Feature X
Developer B starts Feature Y
QA waits for both
Product introduces urgent request Z
Sprint deadline approaches
Half-complete work accumulates
Context switching increases
Nothing reaches production smoothly
The sprint board appears “busy.” But delivery slows down. This creates the illusion of productivity while deployment velocity declines.
The Hidden Cost of Sprint-Based Thinking
Sprint structures unintentionally encourage batch delivery. Teams often delay integration, QA, deployment, and validation until sprint closure.
This creates:
Large deployment risk
QA bottlenecks
Delayed customer feedback
Increased merge conflicts
Artificial deadlines
Burnout cycles
Ironically, teams become “Agile” while shipping less frequently.
The AI Era Changes Delivery Speed Completely
This challenge becomes even more important in the AI-assisted engineering era. Historically, a 1 or 2 week sprint made sense because humans needed time for:
Planning
Development
Refactoring
Documentation
Testing
Deployment preparation
Now AI accelerates major parts of execution. Tasks that previously required days may now take hours.
Boilerplate generation, scaffolding, testing assistance, debugging support, documentation drafting, and even architecture recommendations can happen almost instantly with AI tooling.
The bottleneck is no longer pure coding speed.
The new bottlenecks are:
Validation
Decision making
QA confidence
Production safety
Prioritization
Workflow congestion
This raises a serious question: If implementation takes one hour, what does a two-week sprint even represent?
Would we create:
1-day sprints?
4-hour sprints?
1-hour sprint planning ceremonies?
At some point, sprint boundaries stop matching engineering reality. This is where Kanban becomes significantly more powerful.
Why Kanban Fits High-Velocity AI-Assisted Teams
Kanban adapts naturally to fast-moving environments because it is flow-oriented rather than time-box oriented.
Instead of waiting for sprint completion, teams continuously:
Pull work
Validate work
Ship work
Monitor work
Improve flow
Kanban accepts that delivery speed is variable.
Some tasks may take 30 minutes.
Some may take 3 days.
The system optimizes throughput rather than forcing work into artificial time containers.
The 3-Step Execution Checklist for Transitioning from Scrum to Kanban
Transitioning does not mean abandoning discipline. It means shifting from sprint optimization to flow optimization.
3 step execution
Step 1: Visualize the Entire Delivery Pipeline
Most teams only visualize development status. That is not enough. Your Kanban board should expose the entire product delivery lifecycle.
A healthy engineering Kanban board usually includes stages like:
Backlog
Ready
In Progress
Code Review
QA
Validation
Ready for Deployment
Released
Monitoring
This visibility immediately exposes where work actually gets stuck. Very often, the bottleneck is not development.
It is:
Review delays
QA congestion
Approval dependencies
Deployment hesitation
Kanban makes operational inefficiencies impossible to hide.
Step 2: Aggressively Limit Work in Progress (WIP)
This is the most important transition step. Without WIP limits, Kanban becomes a prettier task board. Set explicit WIP constraints such as:
Maximum 2 tasks per engineer
Maximum 3 tickets in QA
Maximum 5 items in review
When WIP exceeds limits:
Nobody starts new work
Team members help unblock flow
Delivery becomes collaborative instead of isolated
This dramatically reduces:
Context switching
Half-completed features
Sprint spillover
QA overload
Most importantly, it improves deployment consistency.
Step 3: Shift Success Metrics from Velocity to Flow
Scrum teams often become obsessed with velocity. But velocity can be manipulated easily:
Smaller stories
Inflated estimates
Reduced scope
Story splitting
Kanban focuses on healthier metrics:
Cycle Time: How long does work take from start to production?
Lead Time: How long does a request take from idea to customer delivery?
Throughput: How many meaningful items ship consistently?
Flow Efficiency: How much time is spent actively progressing work versus waiting?
These metrics reflect real customer delivery performance.
What Guardrails Are Required for Kanban?
One misconception is that Kanban means “no process.” That is dangerous. High-speed delivery without guardrails creates operational chaos. Especially in AI-assisted environments where development speed increases dramatically. Kanban still requires strong engineering discipline.
Essential Guardrails
Clear Definition of Done
Every task must satisfy:
Code review completed
Tests passed
QA validated
Documentation updated
Monitoring configured
Strong CI/CD Automation
Continuous deployment without automation is unsustainable.
Teams need:
Automated testing
Deployment pipelines
Rollback mechanisms
Feature flags
Observability tooling
Controlled WIP Enforcement
WIP limits should be enforced operationally, not treated as suggestions.
Production Monitoring
Fast deployment requires fast detection.
Monitor:
Errors
Performance degradation
Customer impact
Infrastructure anomalies
Prioritization Discipline
Without sprint boundaries, priorities can shift too frequently. Product leadership must maintain:
Clear prioritization
Stable delivery focus
Reduced interruption frequency
Scrum vs Kanban Is the Wrong Debate
The goal is not choosing a “winning framework.” The real objective is building a delivery system that matches your product, engineering culture, and business speed.
Some teams succeed with Scrum for years. Some teams evolve into Kanban naturally. Some operate with hybrids. What matters is this:
Can your organization continuously deliver value predictably without exhausting the team?
That is the real Agile maturity test.
Final Thoughts
Scrum helped the software industry move away from rigid traditional delivery models. It introduced structure where chaos existed. But modern engineering environments are evolving rapidly.
AI-assisted development is compressing implementation timelines dramatically. The future advantage will not belong to teams that conduct the best sprint ceremonies. It will belong to teams that:
Reduce flow friction
Eliminate bottlenecks
Deploy safely and continuously
Adapt operationally in real time
Kanban is not about removing discipline. It is about optimizing movement.
And in high-velocity software delivery, movement matters more than ritual.
Sometimes I wish I had a Prism of Priorities in my hands.
Not a metaphor, but a real tool. Something I could hold up to every incoming request, every feature idea, every “quick win,” and instantly see its true color; its real weight, its actual impact.
In my mind, it works like light passing through glass. A single request enters as a bright, confident beam, full of urgency and conviction. Then it refracts into a spectrum, revealing what it is truly made of; user value, business impact, technical cost, timing, and sometimes, pure bias.
The Illusion of Clarity
we do not live in a products centric storyland and in reality it might not be as helpful as it sounds.
Because the honest picture of every request would likely create more chaos than clarity. Imagine showing every stakeholder that their “high priority” request breaks into faint, scattered colors when measured against real user needs. Or discovering that multiple “critical” initiatives are simply competing opinions with no grounding in evidence.
As Ben Horowitz said:
“The hard thing about hard things is that there is no formula for dealing with them.”
Prioritization is one of those hard things. There is no perfect framework that removes ambiguity. Only better ways to navigate it.
Products Are Built on Perspectives
Products are not built in isolation. They are shaped by people, and people come with perspectives, incentives, and biases. Every wishlist carries a story;
a sales target to hit,
a customer complaint to resolve,
a feature a competitor just launched,
or simply a belief in what “should” work.
This is where many products quietly drift. According to Marty Cagan, the primary responsibility of a product manager on an empowred product tem is to manage two of the four critical products risks: Value and Viability.
The tension lies in that balance. Value is often assumed. Viability is often negotiated. And both can be distorted by internal bias if left unchecked.
The Role of Corporate Diplomacy
This is where corporate diplomacy becomes an essential skill. Not politics for the sake of survival, but structured communication for clarity. It is about guiding conversations in a way that uncovers what truly matters:
What problem are we solving?
For whom?
Why now?
It is about keeping stakeholders engaged while gradually shifting the conversation from opinions to evidence.
You listen carefully.
You translate requests into hypotheses.
You validate them through data, user behavior, and experiments.
Data does not remove bias entirely, but it anchors decisions in something more stable than intuition alone.
You Don’t Need a Prism
We may never get that perfect Prism of Priorities. But perhaps we do not need one.
Because the real craft of product management is not about revealing a single “true color” of every request. It is about navigating the spectrum; understanding where each input fits, filtering what matters, and continuously aligning the product with the problems it is meant to solve.
Or as Steve Jobs famously said:
“Deciding what not to do is as important as deciding what to do.”
Final Thought
A Prism of Priorities would make things easier, but it would also remove the judgment, context, and nuance that define strong product thinking. The real value lies in how we interpret, challenge, and align; not just what we see.
Sitting in the space where clarity is incomplete requires a different kind of discipline; translating urgency into understanding, and opinions into direction. It comes down to choosing what truly moves the product forward, even when the signal is faint and the noise is loud.
If these ideas resonate, or if you see prioritization differently in your own work, there is always value in exchanging perspectives and learning from real experiences across teams and products.
Last week, I was working on improving user experience for Usermaven. Usermaven helps you accurately track the full customer journey, from first touch to purchase and retention. By unifying product analytics, CRM data, and ad performance, it provides a single source of truth for growth teams.
On the surface, the goal was simple; make the interface cleaner, reduce clutter, and bring important actions closer to the user. But as we started making changes, an interesting tension emerged. Every improvement in clarity seemed to come with a trade-off in familiarity.
Things looked better. Flows felt more structured. But at the same time, elements users were used to interacting with became less visible. That raised some questions for me.
Are we truly improving the experience, or just shifting the complexity somewhere else? This is where UX stops being just design and starts becoming a product decision.
In many products, simplifying the interface often means hiding complexity. Fewer visible options, cleaner layouts, and more focused screens can make things feel better… at least initially.
But there is a trade-off.
When familiar elements move, or commonly used actions become less visible, users may not feel “simplified”; they may feel lost. What looks like better design for new users can create friction for existing ones.
So where is the balance?
Should discoverability be sacrificed for a cleaner experience?
How do you decide what stays visible vs what gets hidden behind interaction?
At what point does “good design” start working against user habits?
👉 Curious how you approach this tension between clarity and familiarity in your products.
I hated it. I was in a difficult conversation with leadership, explaining why we couldn’t ship. The reason? One key person was absent. As a Technical Product Manager, I was new to the setup and hadn’t built this team myself, but I refuse to abandon ownership just because I’m the new person. I was learning from the dynamics of the team and organizational culture.
I realized our delivery was dependent, not designed. If your software delivery engine stops because someone took a sick day, you aren’t running an Agile team; you’re running a bottleneck.
Fixing the Delivery Engine Piece by Piece
I knew I couldn’t fix everything overnight, so I treated the system like a product and started iterating. I focused on shifting from individual dependency to cross-functional ownership.
Created Backups & Shared Context: We stopped letting critical workflows live only in people’s heads.
Rotated Responsibilities: I ensured knowledge wasn’t locked with one person by rotating tasks during Scrum sprints.
Introduced DevOps & Automation: We implemented CI/CD and uptime monitoring to remove manual deployment risks and “surprises”.
Distributed Ownership: I gave the team ownership of upcoming deliveries, empowering them to make strategic decisions rather than just executing tasks.
Within a year, the transformation was clear: the products I led no longer depended on a single point of failure.
Useful Findings for Product Leaders
Through this process of Digital Transformation, I discovered three hard truths about modern product delivery:
The “Bus Factor”:
The bus factor is a risk management metric representing the minimum number of team members who, if suddenly unavailable (e.g., hit by a bus), would cause a project to fail due to lack of critical knowledge. A low bus factor (e.g., 1) indicates high risk, while a higher number indicates a resilient team with shared knowledge.
Agile is About Resilience
Agile is often misunderstood as a set of ceremonies or frameworks like Scrum or Kanban. In reality, Agile is a resilience system. It is the ability of a team to adapt when priorities shift, people change, or uncertainty increases. A truly Agile team does not depend on perfect plans; it is designed to absorb change and continue delivering value.
Documentation is Delivery
When knowledge lives only in people’s heads, it creates hidden dependencies. This leads to delays, confusion, and risk when key individuals are unavailable. This is a form of technical debt that is harder to detect than bad code. Documentation is not overhead. It is what makes delivery repeatable and reliable.
The “Resilient Delivery” Framework
To reduce these issues in your own organization, I suggest moving away from “hero culture” and toward a system-based framework:
hero culture
Pillar 1: Knowledge Liquidity: Use tools like Kanban to visualize not just tasks, but who knows how to do them. If only one name appears on a certain type of ticket, you have a knowledge silo.
Pillar 2: Automated Guardrails: Shift from manual processes to AI-driven automation and CI/CD. Let the machine handle the “how” so the humans can focus on the “why”.
Pillar 3: Strategic Redundancy: Startups don’t have abundance of resources. That requires adaptability essential. Cross-train your team, share context, and enable people to step into adjacent roles when needed.
Closing Thoughts
Look at your setup today: where does everything slow down when one person steps away?. If you are an aspiring Product Manager in or a founder navigating Digital Transformation, don’t wait for a crisis to fix your system. Build for resilience, not just for speed.
By prioritizing shared context and automated guardrails, you ensure that your “product” continues to deliver value even when life happens.
How are you currently handling single points of failure in your delivery process?
From 60 “must-haves” to actually shipping: a practical lesson in prioritization.
I’ve been in situations where stakeholders handed over a list of 60+ things they wanted to achieve—some of them sitting there for years. The frustration was always the same: “Why hasn’t anything been delivered?”
At the same time, the development team was constantly busy. Just not on these things.
That disconnect is more common than we admit.
“Everything is a priority” is the fastest way to achieve nothing
When everything matters, nothing moves
The real issue wasn’t capacity. It was clarity.
When every item is labeled as “important,” teams lose the ability to make meaningful progress. Work gets fragmented, priorities keep shifting, and outcomes stay stuck in limbo.
So instead of trying to push delivery harder, I stepped back and focused on prioritization.
Running a prioritization workshop
I set up a workshop with stakeholders to bring everything into one place and force a conversation around trade-offs.
We used the MoSCoW method:
Must have
Should have
Could have
Won’t have (for now)
It’s simple, intuitive, and works well when you need quick alignment without over complicating things.
The hardest part: “Won’t Do”
As expected, the biggest resistance came with the “Won’t Do” column.
“These are all important. We can’t skip any of them.”
Fair point—on the surface.
So I reframed it:
“This isn’t ‘won’t ever do.’ This is ‘won’t do in the next two quarters.’ If priorities change, we can revisit.”
That small shift made a big difference. It turned a hard rejection into a time-bound decision. Eventually, they agreed.
Breaking the list into reality
Once we started sorting, patterns emerged. Finally wt had two clear groups each further sorted with MoSCoW:
Small improvements: quick wins, incremental value
Big initiatives: larger efforts that needed new thinking or full transformation (epics)
This separation helped a lot. It gave us a practical way to balance short-term delivery with long-term impact.
Forcing focus at the sprint level
For the upcoming sprints, I asked stakeholders to commit to:
1 big initiative
2 small improvements
Alongside that, the team continued working on ongoing initiatives and technical debt.
This wasn’t about limiting ambition. It was about creating focus.
What changed
We didn’t magically deliver all 60 items. But we started shipping.
Small improvements went out faster. Bigger initiatives got proper attention instead of being half-started and abandoned. From the top 10 priorities, we were able to deliver meaningful value within a couple of quarters.
That shift—from activity to outcomes—made all the difference.
Final Thoughts
Prioritization isn’t just stacking features by deadline. It’s an exercise in making trade-offs—often uncomfortable ones.
If you can’t clearly explain the cost of delay for a feature, you’re not really prioritizing. You’re reacting to whoever is the loudest in the room.
Product management requires the discipline—and sometimes the courage—to say “no” to good ideas, so you can say “yes” to the ones that truly move the needle.
How do you handle pushback when you have to deprioritize a stakeholder’s “must-have”?
It has been a long journey in the IT industry—moving from development into leadership roles. One thing remained constant: never standing still. Continuous learning, experimenting, and staying aligned with evolving technology shaped the way I approach products and teams today.
This journey led me to be recognized as a Technical Product Manager, sometimes referred to as a T-Shaped Product Manager. That said, this title does not imply knowing everything. It reflects a balance—depth in one area, with awareness across many.
What T-Shaped Really Means
A T-shaped profile combines broad understanding across disciplines (the horizontal bar) with deep expertise in one area (the vertical bar).
For a Technical Product Manager:
The depth lies in technology
The breadth spans business, user experience, delivery, and stakeholder alignment
This balance enables better decision-making, clearer communication, and more realistic product outcomes.
The Reality of Going Beyond Roles
Throughout my career, I have often gone beyond what was expected. Not to take over someone else’s role, but to ensure the product succeeds.
At the same time, I have been careful not to step into ownership that belongs to others.
This is where things get complicated.
Even when roles are clearly defined, boundaries are not always obvious in practice. Questions naturally arise:
Where does a Technical Product Manager stop and a Solution Architect begin?
How does a Product Manager differ from a Marketing or Growth Manager?
These overlaps are not just theoretical—they create real tension within teams.
When Ambiguity Turns Into Conflict
Role ambiguity often leads to friction in cross-functional teams.
Not because people are wrong—but because:
It challenges ownership
It disrupts comfort zones
It creates a sense of being questioned
In some cases, this tension becomes visible through reactions like:
“Do you want to join the development team?”
Statements like this are rarely about the actual discussion. They reflect discomfort when boundaries feel unclear.
If not handled carefully, such situations can lead to unhealthy team dynamics—where instead of focusing on building great products, individuals begin protecting their space.
And a team with internal conflict will rarely deliver its best work.
Defining the Roles (From Experience)
Product Manager
Owns the vision, problem space, and outcomes
Focuses on users, business goals, and prioritization
Technical Product Manager
Bridges business and technology
Understands systems, constraints, and trade-offs
Challenges decisions constructively while staying outcome-focused
Development Lead / Solution Architect
Owns the technical design and implementation approach
Ensures scalability, performance, and maintainability
How I Approach the T-Shaped Role
Being a T-shaped Technical Product Manager is not about control—it is about clarity and alignment.
From my experience, a few principles help maintain that balance:
1. Go Deep, But Not Too Far
Understanding technical details is important. Owning them is not.
The goal is to:
Ask better questions
Understand trade-offs
Avoid unrealistic expectations
Not to replace engineering decisions.
2. Stay Outcome-Focused
Discussions should always connect back to:
User impact
Business value
Long-term product direction
This keeps conversations grounded and reduces personal friction.
3. Respect Ownership
Every role exists for a reason.
Crossing boundaries occasionally is natural. Staying there is where problems begin.
4. Handle Challenges Carefully
Challenging ideas is necessary. Challenging people is not.
The difference lies in:
How questions are framed
The intent behind them
The respect shown in conversations
Where to Draw the Line
From experience, the line becomes clearer with intent.
Step in when:
Product outcomes are at risk
Trade-offs are unclear
Technical decisions impact user experience
Step back when:
The discussion is purely implementation-focused
The team is aligned on direction
Input starts becoming prescriptive
Final Thought
The T-shaped Technical Product Manager operates in a space that naturally overlaps with others. That overlap is not a problem—it is a necessity in modern product teams.
The real challenge is managing it with awareness.
It is not about knowing everything. It is not about controlling decisions.
It is about connecting perspectives without creating conflict.
And when done right, it turns a group of individuals into a team that builds with clarity, not competition.
