Product Mentality When Building Tech
There is a fine line between building a product strictly according to client requirements and giving the client the best possible product that you can build. Knowing how to balance on this fine line and being able to identify certain aspects of the Product that could be changed for the benefit of the product and ultimately, the client, is a Product Owner’s arena. We unpack the role of a product owner and product mentality when building tech.
Product mentality is an “outside-in” approach that uses external measurements to actively guide the development of the product to maximise value. Simply put, it uses the measure of what the result should be/ do then work backwards as to what processes need to be implemented.
Consider this hypothetical question on a hypothetical scenario: A client approaches you and would like a product where they can watch two movies on Netflix simultaneously, what is your response?
Sales: Yes, of course, we can do that for you! Would you not prefer to watch it on 4 screens?
Business Analyst: I’m sure we could make this work for you, we’ll be in touch with our Developers to see how to adapt the tech.
Product Owner: Why would you want to watch two movies at one time?
To have a Product mentality, you have to be prepared to ask the tough questions and be able to come with a new approach that may not have been thought of before. It’s hard to question the client requirements, but as Product Owners, we must question those requirements to build the best possible product.
By not doing so, you are doing your client a disservice by building something that doesn’t provide the value that was initially conceptualised for. Essentially, the client has hired you for a reason and as their technical service provider, you must provide them with the necessary tools and feedback which will ensure the best possible outcome for their Product.
Of course deadlines, budget, and scope are important, but in the end, it’s all about building the right product for the customer. It’s about continuously optimising the delivered value. A project that meets all the deadlines, within budget and with the original agreed upon scope can still result in a crappy product.
Barry Overeem, Scrum.org
As Product Owners before each new feature delivery or in SovTech’s case, for each new Sprint, there should be a “Business Requirements” meeting where priorities are communicated and the Product Roadmap is reviewed, to agree on what will be covered in the upcoming Sprint. This is a perfect time to sit with the client and ask those tough questions.
Before just agreeing, one must step back and visualise the impacts of what the client is truly asking for. It is in this meeting that you not only protect the Team against unrealistic expectations, by setting mutually understood expectations, but you navigate the client to a solution that is not only achievable but will add the most value to the Product and its users.
An organisation with a product mindset starts to fund products incrementally and iteratively. It provides flexibility that enables experimentation and allows the team to adapt to changes in business priorities
Always have the original concept front of mind. Make sure that every additional feature requested, is in line with the original goal and purpose of the solution. It happens so often that people get side-tracked and would like to add many bells & whistles that don’t compliment the Product in a way that best serves the Product. Make sure to stick on the path by using your Product Roadmap and Product plan as a navigational tool to deliver a product that will exceed expectations.
It is imperative to have a Product Owner that can #adapt to the ever-changing client business environment and still deliver over and above. Keeping the Product first and foremost will prove to be a #worldclass service experience and that is exactly what we aim to achieve. We trust this has been insightful in highlighting the importance of having a product mentality when building tech.
