Build All You Want — But If You Can’t Answer These 3 Questions, Nobody’s Buying Who decides what to build?How is it decided?How do we know it will be useful? These 3 questions look simple on paper — but they separate successful products from those that quietly die after months (or years) of passionate work. And yet, in all my years coaching product teams and leaders across industries, these questions are either skipped entirely or answered with assumptions, opinions, and gut feelings. I’ll never forget a startup founder I met years ago in Palo Alto. Brilliant guy. Huge passion for solving a specific problem — he truly believed his product would change the game. He secured Series A funding, hired a small but talented team, and built a beautifully designed product. It had all the bells and whistles. The engineering was solid. On paper, it was perfect. Two years later — the company folded. The product wasn’t flawed. The idea wasn’t bad. The founder wasn’t lazy. The problem? No one wanted it. There were no buyers! There was no real user research. No discovery process that validated actual pain points. No conversations with real potential customers to even understand if the problem they were solving was important enough for someone to pay for. The founder was solving his problem — not his customer’s. The worst part is the engineering team — the people closest to the technology and often the first to spot feasibility risks — were brought in only after everything was decided. They were there to build, not to think. This is not just a startup problem. I’ve seen the exact same anti-pattern play out in Fortune 100 companies. The process looks a little different, but the dysfunction is the same. => A product idea is pitched — usually by someone high up, a key stakeholder or a Sales head=> A business case is created — complete with speculative cost estimates and fantasy revenue projections, all before a single user interview has taken place.=> A few PowerPoint slides later, leadership buys in.=> The loudest voice — often the HIPPO (Highest Paid Person’s Opinion) — determines what gets funded and prioritized. Here’s my question:When you don’t know the actual user need…When you haven’t built even a rough prototype…When you haven’t tested if people will use it, let alone pay for it…How in the world can you confidently estimate costs or predict revenue? This is how teams end up wasting months (sometimes years) building products that nobody wants. And then they wonder why Agile development didn’t save them. Here’s the hard truth: Agile delivery can’t rescue broken product discovery. The product life cycle itself has to be truly Agile — starting from discovery, not just delivery. One of my most successful coaching engagements was with a large enterprise where this very problem was rampant. The product management team worked in isolation, building roadmaps based on leadership directives, not validated user needs. The engineering teams — full of brilliant minds with years of experience solving real user problems — were handed fully-baked backlogs and told to execute. No room for discovery. No seat at the table. We changed the game by integrating discovery and delivery. Product Owners didn’t just write stories — they worked with users, developers, and designers upfront to validate needs before committing anything to the backlog.Developers weren’t just handed work — they participated in user research, technical spikes, and product experiments, bringing their insights to shape the product early.Senior designers, compliance experts, and architects were looped into discovery efforts from day one — not called in at the last minute to rubber-stamp decisions. This wasn’t a one-time exercise. It became part of how work flowed. The company culture changed which resulted in:Features that solved real problems, not imaginary ones.Less rework and fewer late-stage surprises.A true sense of shared ownership — because the whole team co-created the product vision. Product discovery should not be some optional ‘nice to have’ random activity. If your discovery is broken, your delivery is just a faster way to build the wrong thing. And here’s the important piece — this isn’t just for startups. Big companies with deep pockets and decades of history fall into the same trap when they disconnect discovery from delivery. In the end, product success is not just about how fast you build.It’s also about whether you’re building something worth building at all. Conclusion: The best product leaders I’ve worked with embrace radical humility. They know their gut instinct might be wrong. They trust evidence over assumptions. They actively seek out dissenting opinions from the very people closest to the work — the engineers, designers, and support teams who engage with real users daily. Great products are rarely born in a conference room. They’re born in conversations with users, in prototypes tested early, in collaboration with the very teams who will build them. If you’re not starting there, you’re not really doing product management — you’re just playing business theater. Note: Our ChatBot AgiNomi helped polish my thoughts and ideas on this topic. – Author

The Product Owner (PO) role in Scrum is like a puzzle waiting to be solved. It’s a role that’s both vital and enigmatic. Is it different from a Product Manager’s job, or are they two sides of the same coin? Can it be played solo, or is a team approach the key? Do you need to be a product management pro, or is adaptability more valuable? Is it a full-time commitment, and how closely should a dedicated PO work with their development team? In this blog, we’ll demystify the Product Owner’s journey, answering these questions and more, helping you determine if this role aligns with your aspirations, providing clarity and guidance to help you determine if this could be your ideal career path. Skill #1: Visionary Prowess Product Owners are the visionaries of Agile. They see beyond the now, charting a course to a brighter future for their teams and companies. As a Product Owner, you’ll inspire and lead, turning ideas into goals and shared dreams into reality. As a famous visionary leader, Walt Disney once said, “All our dreams can come true if we have the courage to pursue them.” Similarly, Product Owners transform visions into accomplishments, steering their teams towards success. Learn more about the qualities of a good Product Owner. Skill #2: Profound Business and Domain Knowledge Undoubtedly, having a deep understanding of the business, technology, and domain is a skill that should never be underestimated. It’s a skill that can’t be improvised or substituted. For instance, in my experience working with financial and medical clients, it became evident how crucial domain expertise is for Product Owners. In the financial sector, a Product Owner’s grasp of loans, mortgages, and interest rates is indispensable. It enables effective negotiations with stakeholders and the astute prioritization of requirements. On the other hand, in the medical domain, Product Owners need to be well-versed in premium billing and the intricacies of medical insurance liabilities. Now, imagine if these Product Owners swapped roles – it would be far from seamless. Each domain has its unique language, challenges, and intricacies. So, my advice for anyone considering a role as a Product Owner is to start in an industry you’re passionate about, where you have hands-on experience and profound knowledge. Your domain expertise will be your guiding star as you embark on your journey as a Product Owner. Find out why domain knowledge is essential for Product Owners in this article. Skill #3: Building Strong Stakeholder Relationships and Effective Communication In my coaching experience, I encountered a Product Owner who faced significant challenges due to disagreements with stakeholders from various domains. The pressure of constantly navigating conflicting priorities created a tumultuous environment. This highlighted the critical importance of establishing robust relationships with stakeholders and honing negotiation and consensus-building skills. While it’s true that, by definition, a Product Owner holds the reins of prioritization, practical success hinges on alignment rather than dictation. Operating in isolation and acting as a dictator rarely garners favor. In reality, fostering collaboration and consensus among stakeholders is a key element of effective product ownership. Furthermore, this skill extends to the Product Owner’s role as a motivator. They serve as a driving force, inspiring development teams to unite and work cohesively towards the realization of the product’s vision. In essence, a Product Owner isn’t just a decision-maker; they’re a unifying force, fostering collaboration, and ensuring that all parties move harmoniously toward shared goals. Discover more in How do Great Product Owners help their Teams – Part 1. Skill #4: Quick Decision-Making and calling on Choices A good Product Owner makes quick decisions, especially when things get intense. This skill needs three things: empowerment, decisiveness, and the willingness to make hard choices. This courage to decide quickly and make tough calls needs self confidence. It is well supported with your domain knowledge, strong communication skills, and your strong relationships with stakeholders. Even with all that, being decisive is something you develop. Making rapid, tough choices can have big consequences. During my tenure as a Product Coach in the gaming industry, I vividly recall a pivotal moment. We were on the brink of a game launch when a critical bug emerged, threatening to mar the player experience. The team was in a whirlwind, and all eyes turned to the Product Owner for guidance. In the blink of an eye, the Product Owner had to make a tough call: delay the launch by a few days to ensure perfection. It was a challenging decision, but it ultimately safeguarded the game’s reputation. Such swift and resolute decision-making, bolstered by domain expertise and effective communication, is the hallmark of the role. Learn how to steer clear of pitfalls in decision-making in Steering Clear: 10 Pitfalls Every Product Owner Must Dodge But what about technical know-how and Understanding the Team? One more skill often asked about for aspiring Product Owners is technical expertise. Is it necessary for a Product Owner to have prior experience as a developer-programmer, or qa-tester, or a tech lead, etc.? In my perspective, not necessarily. What truly matters is the Product Owner’s ability to comprehend the team’s work and communicate effectively in their language. For instance, if you’re steering a software team as a Product Owner, you don’t have to be a coder, but it certainly helps to understand coding and how the coders discuss and work together. Working with team and being available to them as needed, can help you get better at this skill. Exploring Diverse Paths to Becoming a Product Owner In the realm of Product Owners, many times internal folks are asked to step up to play this role. Why? Well, as explained before, having domain and industry knowledge is key in being a successful Product Owner. Let’s take a look at the various roles that [can] transition into Product Owner role Product Manager to Product Owner One common route is transitioning from a Product Manager to a Product Owner. Product Managers often deal with customers, pricing, competition and all things on the outside.

Product Owners have a lot on their plate. In fact, quite a lot! They’re the bridge connecting stakeholders, customers, and users, constantly delving into market insights and data to ensure the product stays on track. Product owners are the glue in team dynamics, always ready to address any queries about ongoing sprint work items. Plus, they make sure there’s a consistent flow of fresh, valuable and clear user stories lined up for upcoming sprints. The realm of a product owner is extensive. Passionate and savvy product owners adhere to best practices to sidestep these 10 critical pitfalls. 1.  Product Owners not participating in Sprint Events While the Scrum Guide doesn’t mandate product owners to be present at every daily scrum, competent product owners recognize the value of showing up as often as they can. If I were to handpick the best Scrum teams I’ve collaborated with, I can bet that their product owners were active participants in daily scrums. Surprisingly, there are product owners who opt out of sprint retrospectives. It is equally troubling when teams don’t even extend an invitation to them. Remember, a product owner is an integral cog in the Scrum Team machinery. Their involvement in the Scrum gatherings not only mirrors their dedication to self-betterment but also instills a similar zeal among team members. Commit yourself to steer clear of the First pitfall: Bypassing sprint events. “Success usually comes to those who are too busy to be looking for it.” – Henry David Thoreau 2. Product Owners not empowered and unwilling to make hard decisions  Product owners must possess the ability to make swift decisions, ensuring there’s no lag in the development cycle. Equally important is the assurance that their choices won’t be overturned by a senior executive or anyone higher up the ladder. If a product owner’s decisions are regularly overridden, it sends a ripple effect across the team, leading them to perceive decisions as temporary. The Second pitfall: Lacking the Empowerment to Execute the Role Efficiently. When product owners find themselves in this situation, it’s important to engage with the individuals overruling their decisions. One constructive way to approach this dialogue is to jot down distinct product owner duties on individual sticky notes, noting responsibilities such as: Next, collectively categorize these notes under columns titled ‘Mine’, ‘Theirs’, or ‘Joint’.  Such a well-defined layout of duties often paves the way to garner the necessary autonomy, enabling product owners to thrive in their role. “Leadership is not about being in charge. It is about taking care of those in your charge.” – Simon Sinek 3. Product Owners’ tendency to introduce change mid-Sprint Exceptional product owners assure their development teams that once a sprint plan is set, it remains unchanged. However, in reality, when clients or stakeholders pivot or present new demands, maintaining this assurance can be challenging. The Third pitfall : Introducing Changes Mid-Sprint Rather Than Awaiting the Next.  It’s true; on occasion, certain changes are critical and justifiable to be made during an ongoing sprint. Yet, often they’re not. Product owners need to resist the urge to divert a sprint’s course merely due to stakeholder pressure. To minimize these interruptions, product owners should lean on their Scrum Masters, emphasizing that it’s acceptable to resist new additions midway through a sprint. Many Scrum Masters recognize this, but they may hesitate, fearing confrontation. Assure them – standing firm is alright. A personal strategy I employed to manage my impulse to interfere was to document fresh ideas separately. At times, I’d add them to the Product Backlog. On other occasions, I’d just share it with the Scrum Master and brainstormed together to see if it really made sense to bring it up to the team now or during the refinement sessions. Sometimes, merely offloading the thought brings clarity. “Do not let what you cannot do interfere with what you can do.” – John Wooden 4. Product Owners Master the Art of Refusal Establishing a product vision is central to a product owner’s role, aiming to culminate in a solution that resonates with users. However, exceptional product owners grasp that appeasing every request isn’t the path to building what’s genuinely needed. Recognizing that every affirmation also means sidelining another potential feature is crucial. The Fourth Pitfall: Overcommitting by Rarely Declining Requests. A less obvious consequence of giving in to all requests is the unintentional blocking of a future pivotal, yet-to-emerge requirement. Be discerning when determining future commitments. Remember, ensuring the product’s integrity occasionally necessitates a polite decline. 5. Product Owners Navigate with a Far-Sighted Lens Effective product owners always have an eye on the horizon, setting medium-term product objectives as their guiding star. Whether through a detailed product roadmap or another tool, they maintain this vision to steer their decision-making. The Fifth Pitfall: Getting Entangled in Short-Term Sprint Urgencies.I advocate for adopting quarterly product landmarks. This three-month scope strikes the right balance between casting a forward-looking vision and setting targets that feel tangible. More importantly, it creates a timeframe within which progress is not only noticeable but also rewarding. “The greater danger for most of us isn’t that our aim is too high and we will miss it, but that it is too low and we reach it.” – Michelangelo 6. Product Owners Set the Destination, Not the Path The role of product owners revolves around defining ‘what’ needs to be accomplished. The ‘how’ part? That’s the playground of the developers. Let’s say your vision is to launch a smart coffee maker that preps a user’s favorite brew as soon as their morning alarm rings. Your responsibility? Communicate this vision. The nitty-gritty of realization – whether it’s through integrating with smart home systems or using a dedicated mobile app with alarm sync – that’s for the development team to innovate on. Evade Pitfall #6: Dictating the Route. Whenever you’re assigning tasks or laying out objectives, introspect: Have you provided enough flexibility for the team to chart their course to the destination? “It’s not about the direction you take; it’s about the direction

Jeff Sutherland, the co-creator of Scrum says: “The Product Owner is the CEO of the Product”. Therefore, it’s important to choose the right person for the job. Are you ready to take on the role of a Product Owner? Or are you in search of a Product Owner who possesses good product owner qualities, understands the product owner responsibilities, and displays important product owner characteristics? As a Product Owner (PO), you are the central point of product leadership. You are responsible for maximizing the value of the product and driving it towards better economics. But being a good product owner is not just about achieving results, it’s about building a culture of empathy, support, and growth. Let’s take a look at the qualities, responsibilities, and characteristics of a good product owner. The importance of the role of a product owner cannot be overstated. The product owner is the single voice for communicating what to build and in what order to build it. They are responsible for marshalling people and resources to ensure stakeholder value is delivered. A good product owner ensures that the team works on the most valuable backlog items and accepts the completed work in a timely manner. They have the same goal as the team and work to maximize the return on investment. One of the most important responsibilities of a product owner is to manage the product backlog. This involves prioritizing the product backlog and ensuring that it is shared with the team and stakeholders. A good product owner also shares the product vision to align business and the team. They define acceptance criteria and verify that they are met, collaborate with the development team, and collaborate with the stakeholders. A good product owner possesses certain characteristics that set them apart from the rest. They have domain skills and are visionary. They understand that everything cannot be anticipated and have business, technology, and domain expertise. They also have people skills, which enable them to establish good relationships with stakeholders, negotiate and build consensus, communicate effectively, and motivate the team. Decision-making is another critical aspect of the product owner role. A good product owner is empowered to make decisions, willing to make hard decisions, and is decisive. They take an economic view to balance business and technical issues. Lastly, accountability is essential for a good product owner. They accept responsibility for the product, are committed and available, and act like a Scrum team member. A good product owner is not afraid to take ownership and ensures that the team is focused on the right priorities. In conclusion, being a good product owner is a challenging role that requires a combination of above mentioned qualities, responsibilities, and characteristics. To be successful, a product owner must be a visionary with business, technology, and domain expertise, possess people skills, be a good decision-maker, and be accountable for the product. By doing so, a good product owner can create a culture of empathy, support, and growth that drives the product towards better economics and maximizes the value for stakeholders.

The creation of the PRD (Process Requirement Document) is not wrong in itself, but the bigger issue is when it is created and how extensive it is. Traditionally, the Requirement specification documents were created as part of waterfall projects. Assigned project managers or  technical leads would write a long document pinning all details or requirements for the product that will be worked upon in the short to mid-term future. This is followed by putting detailed design in place, then coding, integration, testing, deployment… We know where that leads to, right? Coming to the present times, I still see a lot of people all over the world, writing PRDs or CUJs (Critical User Journey) as text documents. PRDs are written exhaustively and drive the work done by teams (often referred to as Agile or Scrum teams). Individual team members interpret the requirements and start working on them. If they find something isn’t clear, then they go to the person who created the document for clarification. There are a number of issues with this approach: 1. Writing PRDs exhaustively to drive product development can be wasteful. Refer to the image below. I was first introduced to this image at a training by Kenneth Reubin.  The region – 1 represents a danger zone. Why? Because, at the start of a project, we do not have enough knowledge of what we are actually building, whether customers will like what we build, how the final shape and form of the product will be, etc. But we are exhaustively writing (freezing) the requirements. Do you see the disconnect? Not only is it dangerous, but it is also wasteful, as things will change and a lot of what we are assuming might not hold value as we move forward. The region – 2 indicates that our cumulative product knowledge increases over time, and it is wiser to start with a small set of requirements, work towards creating a prototype, get quick feedback and adjust the direction. If this is what is more useful, then why the heck are we creating such exhaustive requirements in the beginning? 2. The second problem with writing such detailed PRDs is that there is a lot of text to read. Usually, different people read such documents on their own and only bring up items they do not understand or need clarification on. But, what about the rest of the items in the document? Research shows that people misinterpret quite a few things based on their understanding and move forward with it. To understand this, let’s refer to the following images, first introduced to me by my mentor Jeff Patton: Per the images above, you can see how people can misinterpret text documents and this can result in lack of shared understanding and alignment, which can negatively impact the health of products. I recently worked at a large enterprise where senior team members are required to create exhaustive PRDs for their teams. A single technical team member then studies that doc on his / her own and starts to implement the code. No one else in the team knows much about the details in the doc, as they have been handed their own docs on projects they will solely own. This creates silos in a group of people who call them as a team but are only a working group.  The team meets weekly for a sync-up in which everyone talks about the progress they have made and what impediments they are facing. They also give a Red/Yellow/Green type status on whether they are on target towards delivering the project in 6-9-12 months. Often with only a few months remaining, the team members call out that they will not be meeting the original deadline. PRD driven development based on siloed understanding of the requirements leads to such situations. Estimating a humongous piece of work will carry a lot of uncertainties. More the uncertainty, bigger are the unknowns and larger is the chance of that big piece not delivered on time. Instead, strive to build a shared understanding. Tell stories, do not just write them. Sketch, record, use whiteboards. Discuss visually for alignment. Create story maps and do not freeze or hide them. Continue to update and refer to these maps and make them the source of truth. Ask different stakeholders to walk through these maps to validate the assumptions.  Slice the map to target desired outcomes as shown below: Did you notice that every release slice is functional (has the shape and form visible)?  And outcome driven? Working in such manner is conducive towards building a shared understanding and should be foundational to effective product strategy. Conclusion:  Invest in techniques that create shared understanding and empower the developers to write code with empathy. Create visual shared understanding and maintain those artifacts as the source of truth that feeds the Product Backlog. Remember, a flat Product Backlog is a trap. The 2 dimensional journey maps are contextual and help with alignment and validate our assumptions. They obviate the need to create extensive Product Requirement Documents (PRDs) upfront. In addition to the new ways of working, Scrum Masters must continue to challenge the status quo and coach teams, departments and organizations to let go of exhaustive textual documents that reduce visibility, understanding and lead to fake project estimations and roadmaps that are never met. Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more