by Sajal Sarwar Sharma

Why developers should think more like product owners

You have just deployed your long-awaited feature to production after a long and gruesome month of coding, reviewing, and testing (read: a lot of iterations, living the Agile Methodology to the core). You had an all-nighter just the last night and now you just want to take off and sleep peacefully in your cosy warm bed.

In a fast moving startup culture, this is kind of normal for a software developer. Things move fast, the code moves faster, and the requirements — well we’ll just say: Mr. Light Photon, you’ve got a competitor.

In the beginning

I have been working with a healthcare startup for the past three years, and I have seen it grow over this time period. Today, I am going to share some of my learnings — but I am not going to bore you with the plethora of technologies we use to keep the wheels moving.

Rather, today I will be sharing some insights that I have learned over the years, working shoulder to shoulder with some of the most motivating and inspiring business leaders in the industry.

During my early days as a developer, all I used to do was:

Take requirements from the product manager, develop the feature/system, test it, deploy it, go home, sleep and reiterate.

Seems legit. That’s the job of a developer, right?

For two years of my developer life, I lived this routine. I was growing as a software developer, but running a business is not just software development. In fact, it’s just one wheel in the chariot, and there are other wheels that move the chariot along that I knew nothing about.

Changing my mentality

I built stuff, I deployed, and I moved on. I suppose that was the biggest mistake I made. Though business moved along as usual, one day I sat down and contemplated:

“Why am I not caring about the product I have been building over these many months?”

“Isn’t it my responsibility to move the business metric forward?”

“I have built the system from scratch, but is the system actually helping the end user?”

You can safely console yourself by thinking “It’s not in my job description” and moving on. But the last question actually stuck me hard: am I doing anything for society, and is my product actually helping our users lead a better life?

I was faced with a dilemma. Should I keep doing what I was good at (development) or should I start focussing on other areas as well, apart from my usual stuff? At this juncture, I remembered a poem I had read in my childhood by the legendary poet Robert Frost:

Two roads diverged in a wood,

and I took the one less travelled by,

and that has made all the difference.

What I did for the next few months completely changed my perspective on my work. I have learned so much from people I rarely interacted with before. I have started to break the cocoon I had entrapped myself in. There’s a lot to learn, and I’ve just started to scratch the surface.

Here’s what I do now

Step #1

Rather than just taking the requirements from my Product Manager, I brainstorm with him. I started asking the hard questions: Why? Why not? How will it work for the end user? How will it affect the business metric? What are your assumptions and expectations?

Effect: There is a lot more clarity during the planning phase of the product’s development.

Step #2

If possible, I ask someone to talk to our end users to see whether they would like such a change in the system. We get their feedback. If it is not possible to reach out to the end user, we ask people randomly whether they would like to have x, y, or z feature. Getting feedback before building the system is the most important part.

Then I brainstorm again with the Product Manager and refine the requirements according to the feedback received.

Effect: We are closer to getting the complete picture and having a clearer perspective now.

Step #3

Develop the system/feature, test it, and then deploy it to the end user.

Track the journey of the feature just launched, and crunch the numbers every other day. Compare it with the previous business metric.

Effect: We see the deviation of expectation from reality, and that helps us plan better the next time. Every failure is a new learning.

Step #4

Track the user issues on a daily basis. Go through the user tickets twice a day. Listen to their conversations with the operations people. A furious customer will often give you more insights into your product than your product manager, engineering manager, analyst, and product owner combined.

Listen to them, reiterate over the solution, sort it, fix the issue, and apologize. I have heard users swear, and trust me — they swear really badly.

Effect: We know which are some of the most painful points in our system and what our users don’t want.

And at the end of the day: go home, sleep, reiterate.

What I’ve learned

Doing this, I have gained a lot of insights into my own product.

My product manager has taught me how to get the answer to “What my end user actually needs.”

The Engineering team has taught me how to track the user’s journey and how to crunch numbers on a daily basis.

The operations team has been the voice of my end users. They have taken all the thrashings I would have gotten because of bugs I had put into the system.

The product owner has taught me how to think long term and how you can achieve success if you develop a good thought process about the product.

And what made me do all this? That one question:

Why am I doing all this?

This is all my perspective, and it might differ from yours. I completely respect that. But ask the above question to yourself whenever you have some free time. If money is not the only motivator you get as a reply, think again and try to reiterate.

I am thankful to a lot of people who have helped me in my journey, which includes my engineering team, my product team, my operations team, and a lot of other people.