Skip to main content

Rethinking Product Management: Flexibility and Customer Obsession for Success

Listen:

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


Comments

Popular posts from this blog

Deal with corrupted messages in Apache Kafka

Under some strange circumstances it can happen that a message in a Kafka topic is corrupted. This happens often by using 3rd party frameworks together with Kafka. Additionally, Kafka < 0.9 has no lock at Log.read() at the consumer read level, but has a lock on Log.write(). This can cause a rare race condition, as described in KAKFA-2477 [1]. Probably a log entry looks like: ERROR Error processing message, stopping consumer: (kafka.tools.ConsoleConsumer$) kafka.message.InvalidMessageException: Message is corrupt (stored crc = xxxxxxxxxx, computed crc = yyyyyyyyyy Kafka-Tools Kafka stores the offset of every consumer in Zookeeper. To read out the offsets, Kafka provides handy tools [2]. But also zkCli.sh can be used, at least to display the consumer and the stored offsets. First we need to find the consumer for a topic (> Kafka 0.9): bin/kafka-consumer-groups.sh --zookeeper management01:2181 --describe --group test Prior to Kafka 0.9 the only possibility to get this inform

Hive query shows ERROR "too many counters"

A hive job face the odd " Too many counters:"  like Ended Job = job_xxxxxx with exception 'org.apache.hadoop.mapreduce.counters.LimitExceededException(Too many counters: 201 max=200)' FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.MapRedTask Intercepting System.exit(1) These happens when operators are used in queries ( Hive Operators ). Hive creates 4 counters per operator, max upto 1000, plus a few additional counters like file read/write, partitions and tables. Hence the number of counter required is going to be dependent upon the query.  To avoid such exception, configure " mapreduce.job.counters.max " in mapreduce-site.xml to a value above 1000. Hive will fail when he is hitting the 1k counts, but other MR jobs not. A number around 1120 should be a good choice. Using " EXPLAIN EXTENDED " and " grep -ri operators | wc -l " print out the used numbers of operators. Use this value to tweak the MR s

Life hacks for your startup with OpenAI and Bard prompts

OpenAI and Bard   are the most used GenAI tools today; the first one has a massive Microsoft investment, and the other one is an experiment from Google. But did you know that you can also use them to optimize and hack your startup?  For startups, reating pitch scripts, sales emails, and elevator pitches with one (or both) of them helps you not only save time but also validate your marketing and wording. Curios? Here a few prompt hacks for startups to create / improve / validate buyer personas, your startups mission / vision statements, and USP definitions. First Step: Introduce yourself and your startup Introduce yourself, your startup, your website, your idea, your position, and in a few words what you are doing to the chatbot: Prompt : I'm NAME and our startup NAME, with website URL, is doing WHATEVER. With PRODUCT NAME, we aim to change or disrupt INDUSTRY. Bard is able to pull information from your website. I'm not sure if ChatGPT can do that, though. But nevertheless, now