Data Product Management

Key Principles for Building the Best Products and Companies

By
This article argues that modern product work is not about headcount, rituals or corporate theater, but about small, empowered teams building things customers actually care about. It uses a failed “big team equals importance” sustainability project as a cautionary tale and then lays out core principles for healthy product organisations: cross-functional teams, end-to-end ownership, flexible methodology, a crystal-clear vision, real empowerment instead of micromanagement, tight customer feedback loops, outcome-focused metrics and protecting team health. It then gets practical: why shipping features alone does not win, how a hybrid of Kanban flow and agile iteration keeps teams responsive, the mindset shifts that keep a team customer-obsessed, prioritizing with MoSCoW, and Amazon’s working backwards method with an internal press release template, the "Family talk" test and the press release as the red line against overbuilding. Drawing on Nike’s classic “our business is change” mindset and Spotify’s experimentation culture, it frames everything in the company as a product and calls for ditching corporate bullshit in favour of customer-centric, experimental and courageous work that people truly love.

If you're a product person, you know it's not just about the features. It's about building something people actually want and love. But it's easy to get caught up in the weeds: endless feature lists, chasing shiny tech, and forgetting who you're really building for.

A Story From My Corporate Days

We were about to launch a brand-new sustainability product. We'd done the research, got customer feedback, even lined up beta users, everything by the book. Then, in the kickoff meeting, a manager pipes up, "We need at least 30 people to fast-track this."

I looked at him like he'd sprouted a second head. "Why?" I asked. His response? "Because with that many people, we'll be important."

Honestly, it was like my brain short-circuited. What the hell? I told him, "I could snag 100 people from the train station in an hour, but that doesn't mean we'd get anything done." 

Side note: the project died. Not because of a lack of quality team members who actually knew what they were doing, but because "big team equals success" was the mentality. From that point, it was clear that increasing headcount wouldn't work, even when they looped in Accenture, further bloating the team. And this wasn't an isolated event. I've experienced this "importance for my kingdom" thinking everywhere, from startups in their growth phase (Series C and beyond) to established corporations. It's a trap, a very human instinct to cover one's backside. But in a modern company structure, that shouldn't be necessary. If you feel you have to, think twice and maybe it's time to reconsider your future with the company.

I quit shortly after that meeting. Anyhow.

The Key Principles For Modern Product Teams

Here's the truth: Everything in your company is a product. 

From the marketing emails you send to the onboarding process for new hires, it all impacts your success. 

So, let's get back to basics with the principles that'll help you build kick-ass products and companies that thrive and grow. 

  • Cross-Functional Teams: Siloed departments are so last century. Get everyone in the room, designers, engineers, marketers, even the sales team, and build a team that's as diverse as your users. Diversity of thought breeds innovation.
  • End-to-End Ownership: Your product team isn't just there to build. They own the entire product lifecycle, from ideation to maintenance. This creates accountability, ensures everyone's focused on the bigger picture, and empowers them to make meaningful improvements.
  • The Methodology: Forget rigid rules. Design thinking, lean principles, agile practices, pick and choose the tools that work best for your team and your product. Don't be afraid to experiment and adapt as you go. Perfection is in the results, not the process.
  • Crystal Clear Vision: Everyone on your team, from the intern to the CEO, should understand your product vision inside and out. Without this alignment, you're just a bunch of individuals rowing in different directions. A shared vision creates a shared purpose.
  • Empowerment Over Micromanagement: Give your team the autonomy to explore problems and come up with creative solutions. Don't stifle innovation with bureaucracy, trust the people you've hired! Push yourselves, push others. Stretch the possible.
  • The Customer Feedback Loop: Don't guess what your customers want, ask them! Seek continuous feedback through surveys, user research, and direct conversations. Then, use that data to refine your product and deliver real value. Assume nothing.
  • Outcomes, Not Busywork: Forget vanity metrics. Focus on outcomes that truly matter to your users. Are they achieving their goals? Are they getting the value they expect from your product? Your job isn't done until THE job is done.
  • Prioritize Team Health: A burnt-out, unhappy team will never build a great product. Foster a positive culture where people feel supported, appreciated, and empowered to do their best work. Energy givers vs. energy takers.

Method and Priorities in Practice

I moved from Solution Engineer and Solution Architect over Product Manager to CPO, and the principles above only work if the daily method supports them. Here is how that looks for me.

Don't Just Add Features

Experience is critical for building customer loyalty: a great interface sells software. No great customer experience, no sales. Product management isn't about churning out features. It starts with a deep understanding of your customers, the market and your competition. What drives customer behavior? What are their biggest pain points? To answer that you need research, analytics and direct feedback channels. And every touchpoint a customer has with your brand shapes their experience, which goes beyond the product itself.

Kanban Plus Agile

Agile has been a game-changer, but its focus on sprints can get in the way of fast innovation. You've got to be ready to rip up the roadmap and pivot based on customer needs. That's why I mix in Kanban (small "a" agile!). Instead of fixed sprints, a visual board lets my teams prioritize continuously and react to feedback right away. Kanban helps us:

  • Visualize the entire workflow: Everyone sees the big picture, which improves transparency and collaboration.
  • Limit work in progress: Staying focused helps us deliver better work, faster.
  • Keep a continuous flow: No more waiting around for the next sprint to start.
  • Improve constantly: Analyze, discuss, optimize.

Agile methods still have a place. The sweet spot is a hybrid: take Agile's iterations and feedback loops and keep the constant flow Kanban brings.

Customer Obsession Is Key

Everyone tells new product managers it's about bells and whistles, or having tons of apps on the phone to test everything. That's bullshit. Product management is about solving real customer problems so well that customers happily pay, build your product into their daily routine and can't live without it. When you've reached that kind of moat, you're a product manager. Here's the mindset shift I ask for:

  • Deep research is non-negotiable: Demographics are good, but go deeper. Get inside your customers' heads!
  • Map the journey: Find 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 decisions.
  • Never stop asking "why": Don't just build what's requested. Find 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 from project management, business analysis and product development. It sorts tasks or features by importance:

  • Must-Have (M): Essential for success. Without these the project or product is likely useless.
  • Should-Have (S): Important and highly desirable, but the release still has value without them.
  • Could-Have (C): Nice to have, added only if time and resources allow.
  • Won't-Have (W): Out of scope for this release, maybe reconsidered later.

Example for a new e-commerce platform: Must Have is a secure payment system, shopping cart and product search. Should Have is customer reviews, wishlists and discount codes. Could Have is personalized recommendations and a loyalty program. Won't Have (for this release) is in-app chat support and integration with physical store inventory.

It gives the team a clear focus on what users really need, makes priorities transparent across teams and stakeholders, and builds a vertical "get it done" culture: sales knows the customer, marketing needs to know the customer, development has to understand both.

It Works

We build our products this way. Every product has a Kanban board, so we react to user feedback right away and prioritize bug fixes alongside new features. We combine agile sprints with Kanban for experiments and A/B testing, and use competitor research to get a feel for where the market is going. The right method always depends on your goals and geography. But if you want insane growth, obsess over your customers, balance strategy with flexibility, and build a culture of constant learning. Flexibility + customer focus = 🚀

Start With the Customer and Work Backwards

A tool that puts the customer feedback loop and a crystal clear vision into practice is Amazon's "working backwards". Instead of building a product and then figuring out how to sell it, you start with the customer. It works for any product decision, but it matters most when you build something new.

The Press Release Exercise

Before anything gets built, the product manager writes a press release for customers: their pain points, why current solutions fall short, and how the new product fixes that. If the benefits don't get customers excited, keep tweaking the press release. It's way easier and cheaper to change a press release than the product. Here's the template I use:

  • Main header: A product name anyone understands right away, like "Ultra-compact power charger"
  • Subheading: One subtitle, not more than 150 chars, like "Never run out of power for your mobiles"
  • Short overview: A direct, logical summary. The customer will never read it all, so keep it short.
  • Problem: What does the product solve? Add data and market studies, like "over 60% of mobile device users run out of power daily and can't recharge in time"
  • Solution: How does your product solve that problem? Two short, well written sentences.
  • Quote from a sparring partner: A quote from a peer can be a sign that there is a market (for the powerbank in the example I doubt it, the market is flooded)
  • Starting point: An easy explanation of how to get going.
  • Hypothetical customer review: A review that describes the benefit the customer felt.
  • CTA: Where to get it, or where to find more information.

How To Write It

It's an internal press release, but you can also send it to design partners and customers in your product discovery program to get feedback. Keep it short and simple, with paragraphs of 3-4 sentences. Think like your customer: what do they need, want and dream about? If you struggle to describe the value and why the customer should buy it, your idea is probably going to fail hard.

I also like a style I call "Family talk". At the family dinner someone asks what you're working on, and you explain the product to your kids and parents. Listen to what they understood. That cuts out all the technical and product jargon we use. I often ask PMs to write me a tweet about the product. If they really worked backwards, that should be easy.

Why It Works

Once the project runs, the press release is the red line. The team can always ask: "Are we building what we said in the press release?" If they spend time and money on features that aren't in it, that's overbuilding, and they need to step back and figure out why. Extra features nobody asked for add development time and maintenance cost, and they rarely add enough value to make it into the press release anyway.

The Product Principles from Nike

Nike's legendary 1977 memo laid out 10 principles that still resonate today. I won't write them all down here, only the most important ones. The philosophy is more on point than ever, now that everything is technology. 

Keep experimenting and trying new things. It is the only way to stay ahead of the curve.
That sums up the spirit needed to build awesome products and companies, echoing the principles Nike established nearly five decades ago.
  1. Our business is change: Embrace it. Don't be afraid to disrupt yourselves.
  2. We're on offense, all the time: Play to win. Take risks, push boundaries, and never settle for "good enough."
  3. Break the rules. Fight the law: Challenge assumptions, question the status quo, and find new ways to do things.
  4. This is as much about battle as about business: Be passionate. Fight for your ideas, your team, and your customers.

These principles aren't just for product teams, they're a roadmap for any organization that wants to thrive. So, go out there and build products (and companies) that people love!

TL;DR

Building a successful company is like building a great product, it requires a customer-centric mindset, agility,empowered teams, data-driven decisions, and a strong culture. Embrace these principles, ditch the corporate BS, and you'll build products (and companies) that actually matter.

Need help with distributed systems, backend engineering or data platforms? See my consulting services.

Alexander Alten

Alexander Alten

Founder of Scalytics, co-creator and PMC member of Apache Wayang, and author of KafScale. I write about Kafka, streaming, data platforms, IoT and AI agent infrastructure in production.