Skip to main content

Rethinking Product Management: Flexibility and Customer Obsession for Success

Struggling with delivery, architecture alignment, or platform stability?

I help teams fix systemic engineering issues: processes, architecture, and clarity.
→ See how I work with teams.


This article distills years of experience moving from engineering into product leadership into a simple truth: great products win because they obsess over customer experience, not feature volume. It argues against feature-churn and blind adherence to rigid Agile rituals, advocating instead for a hybrid model where Kanban provides flow, focus and instant responsiveness while Agile supplies structure and iteration. The core message is a mindset shift—deep research, mapping customer journeys, validating data, asking “why” relentlessly and prioritizing with discipline through frameworks like MoSCoW. Combined, these practices help teams build products that solve real problems so effectively that they become irreplaceable in users’ routines. The result is faster learning, stronger differentiation, and a product culture capable of sustaining long-term growth.

I've been building products for a long time now, moving from Solution Engineer and Solution Architect over Product Manager to my current role as CPO. Along the way, I've seen the landscape shift dramatically. One thing's for sure: if you want to create products that customers truly love (and that drive real business results), you need to stay obsessed with their experience. That means rethinking some of the old "tried and true" ways of doing things.

Don't: Just Adding Features

Experience is critical for building customer loyalty: A great interface sells software. No great customer experience, no sales.

Product management isn't about mindlessly churning out features. It starts with a deep understanding of your customers, the market and your competition. What drives the customer behavior? What are their biggest pain points? 

To answer those questions, you need a toolkit that includes research, analytics, and direct feedback channels. This empathy for your customers is the foundation upon which great products are built.

Of course, every interaction a customer has with your brand shapes their experience – that goes beyond the product itself. As a product manager, you have to make sure that every touchpoint is valuable, seamless, and consistent.   

When Agile Isn't Enough

Agile has been a game-changer, but sometimes its focus on sprints can actually get in the way of fast-paced innovation. As a product manager, you've got to be ready to rip up the roadmap and pivot quickly based on customer needs. That's why I'm a fan of incorporating some Kanban methodology to stay agile (small "a" agile!).

Kanban for the Win

Instead of fixed sprints, Kanban uses a visual workflow board. This gives my teams incredible flexibility. We can continuously prioritize what matters most, responding to feedback in real-time. Kanban helps us:

  • Visualize our entire workflow: Everyone sees the big picture, improving transparency and collaboration.
  • Limit Work-in-Progress: Staying focused helps us deliver better work, faster.
  • Maintain continuous flow: No more waiting around for the next sprint to start.
  • Improve constantly: Analyze, discuss, optimize – Kanban encourages ongoing learning and improvement.

The Hybrid Approach

Don't get me wrong– Agile methods still have a place. Finding a hybrid approach is often the sweet spot. Leverage Agile's iterative nature and feedback loops while maintaining the constant flow that Kanban brings to the table.

The Do's

Customer-Obsession is Key

Getting into product management, everyone tells you it's about bells and whistles. Or a good product manager has tons of apps on the mobile to test everything. That's bullshit. Product management it's about solving real customer problems in a way that customers are happy to pay any amount to get your product, integrate them into their daily routine and can't live or survive without them. When you've reached that kind of moat, you're a product manager. 

Here's the mindset shift I challenge new product managers to make:

  • Deep research is non-negotiable: Demographics are good, but go deeper. Get inside your customers' heads!
  • Map the Journey: Uncover pain points and opportunities by visualizing the entire customer experience.
  • Data is your friend: Track how customers use your product to validate assumptions and guide your decisions.
  • Never Stop Asking "Why": Don't just build what's requested. Uncover the root of the problem you're solving.
  • Iterate and Experiment: Smaller, frequent releases get feedback faster. Adjust accordingly.
  • Prioritize Ruthlessly: Focus on what delivers the most customer value. Use something like MoSCoW for tough decisions.

Hey stop, what the heck is MoSCoW?

MoSCoW is a prioritization technique used in project management, business analysis, and product development. It helps to categorize tasks or features on team level based on their level of importance. Let's break it down:

  • Must-Have (M): These are the essential requirements for project success. Failure to deliver these will likely make the project or product useless.
  • Should-Have (S): These features are important and highly desirable, but the project will still have value if they are not delivered or stretched.
  • Could-Have (C): These items are nice-to-have, delivering additional value, but not critical. They are added only if time and resources allow.
  • Won't-Have (W): These requirements are deemed out of scope for the current project or release. They might be reconsidered for future projects or iterations.

Why use MoSCoW?

  • Clear Focus: Helps your team to agree on which features are truly essential to meet users' needs.
  • Efficient Time Management: Creates a framework to prioritize tasks effectively.
  • Transparency and Collaboration: Promotes communication among multiple teams and stakeholders
  • Vertical product understanding: Builds a vertical "get it done" culture: Sales knows the customer, marketing needs to know the customer, development has to understand both

Example: Let's say you're building a new e-commerce platform. Here's how MoSCoW apply:

  • Must Have: Secure payment system, shopping cart, product search
  • Should Have: Customer reviews, wishlists, discount code functionality
  • Could Have: Personalized recommendations, loyalty program
  • Won't Have: In-app chat support, integration with a physical store inventory (for this release)

It Works!

We build our products this way. Every product has a kanban board and let us react instantly to user feedback, prioritizing bug fixes alongside new features. We combine agile sprints with kanban for experimentation and A/B testing, using competitor research to synthesize a future market voice. And even in our space and niche, we've used this to build a portal people actually love, interact with and getting input from all user types along the way.

The right methodology always depends on your goals and geography. But if you want to make insane growth happen, obsess over your customers, find the right balance between strategy and flexibility, and implement a culture of constant learning. That's the product management mindset that truly moves business success, and your career, forward. Never stop!

Tl;dr

Flexibility + Customer Focus = 🚀

This approach may feel different, but it pays off:

  • Truly understand your customers' needs
  • Build moat around the bits and pieces
  • Monitor competition and market movements 
  • Adapt quickly to changing market conditions
  • Boost collaboration across teams


If you need help with distributed systems, backend engineering, or data platforms, check my Services.

Most read articles

Building a Model-Agnostic Multi-Agent System with OpenClaw

Over one week we rebuilt our AI stack around OpenClaw’s multi-agent architecture to avoid provider lock-in and stop wasting premium tokens. By aligning models to tasks, diversifying fallbacks across providers, enforcing minimal tool access, and switching to memory-first workflows with ephemeral sessions, we reduced token usage per task by about 70% and cut our monthly bill by 77% while improving operational resilience. How We Achieved 77% Cost Reduction and Provider Independence Over the past week, we rebuilt our AI infrastructure around OpenClaw’s multi-agent architecture. The result was a 77% cost reduction , provider independence , and a delegation system that routes work to the most cost-effective model for each job. Below is the technical journey of optimizing a 7-agent squad with OpenClaw. The Challenge: Model Provider Lock-In We started with a simple problem: our entire squad defaulted to a single model provider. This created three issues: Cost inefficiency beca...

BacNet => MQTT in Production: The Real Cost of Bridging BACnet to MQTT at Scale

bacnet2mqtt looks simple in a README and expensive in production. Once BACnet polling, reconnection behavior, stale state, and MQTT publishing collide, teams discover they are not deploying a lightweight adapter but operating infrastructure. This article breaks down where bacnet2mqtt works, where it becomes a bottleneck, and which production patterns reduce the operational damage before incidents, backlogs, and silent data loss turn a building integration into a long-running engineering problem. I inherited a building controls integration problem 18 months ago. Three office floors. 217 BACnet sensors covering temperature, occupancy, and HVAC actuators. The data was trapped inside the building automation network while the business wanted analytics, reporting, and compliance visibility in the data platform. The obvious answer looked easy enough: deploy bacnet2mqtt, bridge BACnet into MQTT, and push the stream into the lakehouse stack. The repository made it sound like a w...

Connect BACnet to the Cloud with bacnet-mqtt-gateway

The bacnet-mqtt-gateway project is an open source protocol bridge that translates BACnet building automation traffic into MQTT messages for cloud and IoT systems. It provides discovery, polling, bidirectional writes, APIs, security, and easy deployment via Docker. Many enterprises struggle to unify BACnet with modern data pipelines and cloud platforms because BACnet is local-network only and not cloud ready. This gateway provides a scalable, secure, production-ready adapter for MQTT ecosystems and smart building integrations. The Problem with BACnet Building automation runs on BACnet . HVAC controllers, lighting systems, metering equipment: they all speak ASHRAE 135 . The protocol handles local control loops well. It fails at cloud ingress. BACnet relies on UDP broadcasts. These do not route over the internet or into VPCs. Your chiller controller cannot talk to AWS IoT Core . Your VAV box cannot publish to an MQTT broker. The air gap between operational technology and modern cl...