Product Owner for a Weekend

Vitaliy Stanyshevskyy
5 min readApr 15, 2019

--

One year ago I participated in a local charity hackathon named KindHack 2018. At this event, Ukrainian NGOs present their vision and recruit the team of designers and developers to build some software (a website or an app) to help the organization achieve its goal.

At that event, I met Katya Myachina, Yulia Kovalchuk and started to work on vpershe.com — the sex ed website for the teenagers in Ukraine. We released vpershe.com on 1st of September 2018 and it’s doing great — people constantly visit it and engage with the content.

However, I’m the only one developer at the project left so far and having full-time developer job makes it hard to contribute on a regular basis. The backlog grows faster than I can burn it down.

So this year we applied to KindHack 2019 to get help from other developers and implement one cool idea — interactive text adventure on the website. I was honored to make the presentation — pitch to recruit the team to work on our idea. And I had to lead the project.

We inspired by Once you go blck by @lpanch

Being a product owner is a completely new role for me, so here’s what I’ve learned that weekend.

One role at a time

This was the first time I’ve tried myself in the product owner role. I had the technical vision of how to implement the game, but I decided to put aside my IDE and do not produce a line of code for a few reasons:

  • To test my soft skills. I speak code, but speaking requirements is a kind of art, which I’d like to master.
  • To not put pressure on the team. Hackathon is a crazy and stressful environment to be in and a lot of tech requirements might destroy the moral.
  • To train my ability to tolerate uncertainty.
  • To have fun and to be surprised with the final result.

Another type of creativity

Some people think that being a developer is boring — it’s a technical job that requires no creativity. However, I think that at least 30% of my time is actually a creative activity. Before jumping in and writing all those for and if -s I think a lot about the best approach to resolve the problem with.

Product owner position puts you on the other side — you think more about the final result — a problem to solve, customer satisfaction, and user experience.

On the day before the hackathon, I found myself writing requirements with too many technical details — where it should be hosted, what properties the admin page should have etc. I decided to throw half of it away and take only the main ideas. The team pick it up and start asking questions, which led me to the next insight.

Your idea can’t be 100% ready

I spent a lot of time thinking about the game idea. I had the vision, I had the requirements I knew I can make it on my own. But when I’ve got into the room with 5 bright minds that started to shot the questions at me, I realized that my idea was quite limited and I haven’t managed to think about it out of the box.

The questions itself were fantastic and we came up with the improved version of the game, keeping in mind the initial requirements. The conversation with the strangers (we’ve met for the first time that day) which have variate experience, including game-development, web-development, design, and illustration, was the brightest experience for that weekend.

Decision-making is a hard work

When I joined the software development industry 8 years ago, I thought that being a product owner is super easy. “They only say yes or no” — was my point of view. During the hackathon, I made a lot of decisions. And making a choice regarding the future of your idea or project is hard. It drains your energy. Every time I had to evaluate the question/idea, compare it with my vision, think a few steps ahead and predict if it would hurt the product or would the change make it better.

I like to think about ideas like a limited number of steps you can take during the day. This number gets bigger the more you practice but it’s better to be prepared and to have more data before making the decision.

Micro management and trust

As I mentioned previously, during the brain-storming and requirements clarification the team came up with a slightly different vision of the game. That vision was quite awesome, however, I thought that it will be challenging to implement. I was worried that the team will not finish it in time.

At that moment I realized that I’m the PO and the team has to figure it out on their own. Instead of jumping in and reducing the scope, and arguing about the time-frames/complexity, I’ve set the priorities of the features we’ve discussed. And I stopped thinking about the technical side.

I was surprised and proud of the team that took the priorities into the consideration, built MVP in 30 hours and demoed it after.

They took second place among all the teams. Well done!

Summary

Having a chance to practice another role is a great experience. I learned a lot that weekend — creativity, trust, ability to cooperate and delegate are the basics for being a good team player, leader and product owner.

Hackathons are challenging and stressful for me. Every time at the end of the event I make a promise that I will not do it again. But after that I think of the experience I gained there and change my mind. Will see if I’ll participate next year ;) .

I’m also very proud that vpershe.com got a nice MVP of the game that will be published on the web site soon. Way to go!

--

--