Building products is tough. Defining them well is arguably tougher. There is always a tendency for product owners to try to define every different use case possible for their product. I personally had a tough time with this. I always thought, "Since I own the product, I need to know every possible way the product will be used, and how it could be useful to a user."
While there is some truth to this statement, there's a flaw with this thought process. It insinuates that I, and only I, have a responsibility to predict what issues may come up when we launched new features. I have yet to find an individual who is able to predict exactly how a feature will be received 100% of the time.
The reality is that it takes a village to raise a great product. You need your best and brightest jumping into the user's journey with you. By over defining, you not only disengage some of your free thinkers, you also give potential slackers a way to point the finger back at you. It's a negative sum situation.
An additional point: when coming up with feature ideas, I also engage my customers and professional network just to see what concerns or value props we may have missed internally. Your responsibility as a product owner is to gather data and communicate it effectively -- not come up with features in a vacuum and disengage your team.
When you build a product, you have to have clarity of what you want to build. To arrive at that clarity comes rationale for why you're building what you're building, and who you're building it for. Sadly, when I see a lot of product requirements, these latter two points are missed. This exact problem is a core reason why a User Story is valuable. If I were to write the User Story format in a slightly different way:
As a "who" I want to "what" so that I can "why".
Describing the what is ambiguous without defining why and who.
I've noticed more and more, people are diverting from User Stories into mockups with simple annotations. Unless the mockups are supplemented by a verbal communication of your why and who and diligent note taking, you cannot rely on this methodology. Without sufficient context, your developers function less like artists and more like robots. Ideally your product definition is perfect, but let's be honest, it never is. By treating your developers like coding machines, you're losing a very powerful mindshare that will inevitably lead to negative outcomes like the one illustrated above.
A good product idea sells itself; delivering requires nuance. As a founder, I've had to struggle with this dichotomy between selling our product and actually delivering on promises made.
Finding a balance is especially difficult given how customers are saturated with information. Hype cycles abound, you need to distill your messaging into something that hooks onto a burning pain point. You can't worry about how you'll get the job done, who will do it, or when it will be delivered. You're really focusing selling a solution to a pain point. As a startup, if you can't get to that point, you cannot sell.
But let's assume you're great at identifying a customer's pain point and even finding a solution. What adds more complexity is making sure you don't overpromise and underdeliver. I've realized as a Product Owner, I have to be acutely aware of the latest and greatest tech, because it will inevitably come up in customer demos. Unfortunately, this can often lead to unreasonable requests, or even make my current product look inadequate.
For example, I've developed standard responses for when customers request things like:
By being in tune with market trends, I can help my customer align their expectations around what is realistic on delivery, and more importantly, make sure they're excited about our current Product and not something on the roadmap.
The biggest problem with effort estimates is that most humans don't know what they don't know, and that is precisely what causes schedules to get out of sync.
But that doesn't mean you should avoid estimations entirely. In fact, that makes it more imperative that you track how people are estimating their work, and observe any trends that could be parsed out. For example, my most productive developer consistently underestimates efforts, however, the end result is always the cleanest code, and the most stable product.
I'll take that any day over someone who delivers exactly within the timeline they committed to, but the product is sub par. The onus is on me to figure out how my teammate is thinking about his/her job. If I know they're a very ambitious and eager developer, I usually know they'll overestimate their initial abilities, and give me a really low estimate, so I multiply the effort by ~3.
This helps me build realistic expectations about how features will be delivered. I can then communicate schedule and expectations better to my customer and higher-ups. Lastly, this keeps me in better sync with my team, and gets them on the track of being more realistic and honest in the long-run.
If you're giving feedback on a SPECIFIC deliverable, please use an appropriate formal communication methodology. When you log something within formal communication (whether it is in an email, ticket, issue or task), you create a clear system of record.
Simply firing off a quick text or chat may be easy for you in the short-term, but it creates a headache in the long-term. How will you follow up and see if your feedback was implemented. How can you perform a proper retrospective? That's why we've included communication INSIDE of our Actions. Check out Profecta to learn more or read our post on why real time may not be the right time for your Product Team.