Things I Realised After My First 18 Months as a Product Owner
The last 18 months have been a bit of a wild ride. The transition from engineering to product management wasn’t an easy one. I love technology. With my interest in thought leadership, I believe that I would contribute better to tech using my strategic skills than with programming skills. The challenges in the new role and the books I’ve read in the past few months have changed my perspective about various things. Here is a reflection of my current thoughts.
#1 Tech decisions are directly correlated to the success of the product. POs generally have little say in them
This is most relevant when it comes to choosing a third-party product, paid service, open-source library or consulting vendor. When a third-party entity is chosen from a pool of similar entities available in the market, the choices that are made would significantly affect the development cycles. Any limitations that come with this entity have to be accepted as it is. Changing the choice, especially after a long term of use, requires herculean efforts.
#2 Diverse backgrounds make a good product org
If everyone in a guild thinks the same way, then that defeats the purpose of having a guild. Understanding the business and the market is a critical product skill. So is understanding tech, finance and marketing. It’s hard to find individuals who are experts in all these. But it’s possible to build a product org with complementary skills. If we look closely, we’ll realise that each product/team might need a different kind of PO. Some squads might work better with a highly technical PO while other squads might need someone with more exposure to marketing and e-commerce. Product orgs work better when it has members from diverse career backgrounds as our backgrounds profoundly influence the way we think.
#3 Either build a product that the market needs or build a product that will create a market need
Building features that nobody wants will just burn the budget. Figure out if the market implicitly is asking for the said feature. Alternatively, explore whether the feature or product as a whole can explicitly create a new market (Like how Pop-it created a toddler customer base). If the suggested product or feature is not falling into either of these categories, then it’s better not to go ahead.
#4 ‘Process’ keeps the wheel consistently rolling. At the same time, heavy processes can be a bad thing. There needs to be a balance
Product development is a very dynamic space. Ideas at times get lost in translation (Product English != Engineering English). Traceability is as complex as the problem at hand. And great leaders come and go. Headache sprouting from these three can be avoided if the organisation is process oriented.
In the beginning, in most companies, decision-making will depend heavily on certain individuals. But once the company grows, processes are essential to keep the progress wheel rolling. It is also easier to align day-to-day work with the strategy if processes are in place.
That being said, too many processes can hurt things like product discovery and product marketing. There needs to be a proper balance.
#5 Every PM framework is relevant in their own way
From the famous Spotify squads to GIST planning, every PM framework has its unique way of building a product that sells. They all work as long as they are adapted in the right way under the right circumstances.
Amazon’s working backwards has proven to work wonders for them, but startups that seem to have copied that approach as it is aren’t always seeing the same results. JTBD (Job-to-be-done) works by focusing on user scenarios while Pragmatic marketing focuses on user personas. The question of whether scenarios or personas should be given importance depends on the business problem at hand. MVP works well when there is a lot to learn while the product is being developed. Design sprints probably work best for interactive platforms (Medium and Slack are famous for using them)
Strictly following one of these existing frameworks might not be the best idea. Creating a recipe by borrowing concepts from relevant areas would work better. Every organisation is different. Every team within the organisation is different. Usually, there isn’t one solution that fit them all. I believe it’s the product team’s duty to figure out, collaboratively, what works well for the organisation.
#6 SaFe is Waterfall in disguise. Sometimes it works, mostly it doesn’t
True agile advocates are seldom fans of SaFe. Yet many senior leaders vote for SaFe cause of the amount of visibility it gifts them. With SaFe, there is an expectation set on what happens at the end of the PI. Even if all PI goals aren’t achieved due to unforeseen situations(Think log4j), it can still serve as a checkpoint towards the alignment to product strategy.
SaFe does take out a large amount of agility from development. For many products, being not agile enough is a curse. The question of whether SaFe would work or not depends on the product’s needs and the organisation’s culture.
#7 Newsletters are a good way to keep internal teams motivated and external customers engaged
When I used to be a tech lead, I used to wonder why there was a lot of fuss about newsletters in my old company. Every Friday, there was a mail going out to internal development teams about deliveries, achievements, a what-I-did-last-weekend section and some fun interviews. Every quarter, customers were sent another newsletter about the product, what is coming next, requests for feedback and similar things. The nature of both letters was carefully crafted by content writers. I miss those product newsletters now and have realised the significant difference they can make when it comes to keeping internal teams motivated.
In a nutshell, what I have learned so far is that having a diverse product org and following a framework that suit’s the organisation’s needs and culture is essential for the long-term success of any product. While there are a few things like engineering decisions that are not under the control of the product, trusting the team and keeping them motivated is the way the product needs to move forward. Aligning the team’s work with the strategy is one of the primary functions of a PO while creating the product vision, objectives and strategy that’s set up for success is the primary function of product leadership.
I see myself as a young student in this discipline. I might or might not be right at multiple places. I might or might not have the same views in the future. If you strongly disagree in any of the above, do let me know. I’m keen to understand your perspectives. After all, when we open ourselves to multiple perspectives, we learn and grow.