A Product Owner’s non-technicality is not a problem. Their lack of product vision is. See 5 tips for starting Product Owners.
The beauty of working in the IT industry is that you take on new challenges pretty much every day. However, taking on a role of a Product Owner in a digital product development process was quite intimidating for me, a person working in communications for most of my career.
I’m a Head of Marketing with no real technical background. So it always made me wonder—is there really such a big difference between a technical and a non-technical Product Owner? Drawing from my recent experience and some discussions I had with software developers in our team, I’ve decided to gather some tips for people who may find themselves in a similar situation.
5 tips for new & non-technical Product Owners
The technical advantage doesn’t have to be unfair
There is no point in pretending there is no difference between a Product Owner with- and without a technical background.
Technical Product Owners have an advantage when it comes to communicating with the dev team or being a proxy between the in-house team and the external service provider. They understand technical nuances and are able to pitch some solutions and create user stories. Setting acceptance criteria is a natural process for them.
The developers I’ve discussed this matter with say that even though they can see the difference between working with technical vs. non-technical Product Owners, it’s not automatically an issue.
What’s crucial in a Product Owner’s role is that:
- They have a clear vision of the product.
- They are decisive and focused.
- They have motivation.
Have a clear vision for your product
Having a clear vision for a product is key to a much smoother development process. Understanding the needs of your users and customers, having particular goals in mind—all of this makes the process of making the right design and development decisions infinitely easier. It’s incredibly difficult to create user stories and prioritize features without knowing what exactly we want to achieve.
You need to keep the goal in mind throughout the whole process. What is the purpose of this component? What is the benefit for the user? If you’re not sure how to get there - that’s ok, that’s why you hired a skilled team. But if you don’t know the goal behind a feature, you might have a problem. You’re the one responsible for the business objectives of your solution.
It’s always good to start with your good old “WHY?” and “WHAT?”. It will make the development process just about the “HOWs?”. And to figure them out you’ll have the support of a whole development team. Together you’ll be able to find the best working solution.
To clarify the vision, you can start with a Product Design Workshop that will help you organize the whole development process. It can also help you avoid the pitfall of scheduling too many tasks all at once or prioritizing too many features for the initial release.
Don’t be scared to make a decision
If you want the work to go smoothly, remember that you need to be the person that makes the final call. Don’t leave it up to the developers to decide when the feature is ready. You’re the one that knows the needs the product has to fulfill. The developers are usually a bunch of smart people—which often means that they can have tendencies to overcomplicate things. It’s because they want the functionality to cover all possible use case scenarios. Your role is to cut this short as you don’t want to end up with an overcomplicated feature.
When working with a development agency, it is also helpful to realize that you don’t order a readily available digital product—it’s not a shop. You order work from a skilled team that will do everything they can to create a product that you came up with. But it’s not like it’s ready. It needs to be developed. And only a product owner has the necessary knowledge of how the product will be handled (go-to-market strategy, further development plans, a team that will be responsible for the product internally, users, etc.). That's why the PO needs to be the person making the final decisions.
“Enter a motivational quote here”
The Product Owner needs to be motivated to find the most optimal solutions and you can be that person even without a technical background. But only if you know your users and truly believe in the value your product can add to their lives.
It’s important to be present, don’t leave the development team on its own because it leaves a lot of room for speculation as to what was meant to be delivered. You don’t want the team to lose the business context of their work. It’s your role to specify what needs to be delivered and describe the acceptance criteria. Otherwise, you might not get what you’ve expected. Let’s take a task like a “login panel”: do you want the user to be able to log via social media profiles? Which ones? Or should it be email-only? You get the point.
Ask questions
I was surprised by how much you can pick up just by listening to a discussion of a tech team. But I’ve learned even more by asking direct questions. “Is it possible to…?”, “What’s the difference between…?” — I think I’ve asked that a hundred times during the development process and have no regrets about it. Was it annoying? Maybe. Was it necessary and helpful at the end of the day? Absolutely. After all, it was the only way to assure our mutual understanding and also a great tool to build trust. The team knew that if I don’t understand something, I’ll ask about it instead of nodding and pretending it’s all clear (which could generate some issues further down the process).
To be a Product Owner - closing thoughts
Being a Product Owner is a responsible job, but a very satisfying one. My final piece of advice would be this: come prepared, know your vision, and don’t stress out. With the right team by your side, you’re up for a great adventure. And a great working product at the finish line.
Check out also
