Life in Tech(ni)Color(s)

What does a Product Manager do? Let us discover that together! I still have no clue.
By Camelia Gui Posted 24 August 2016

Life in Tech(ni)Color(s)

Life in Tech(ni)Color(s)

I used to be a BA and I used to work in Cluj's software outsourcing. Where else? I now work in a product company and they say I'm a Product Manager. Explain that to my grandparents!

The road between those two roles is like running a never-ending marathon of which I'm enjoying every step… well, if not always enjoying, at least living it to the fullest. So grannie still asks- what is it that you do? Dad says- she's a manager now! Grandpa says my job is to use the computer a lot and type fast. My husband says I'm organizing things and my friends say I'm sort of a Duracell battery. But I say I just bring colors into the life of techies.

What are PM's after all? Experts in context switching? Excellent communicators? Domain experts? Control freaks? Good organizers? In the last 14 months, I've barely scratched the surface of what product management is, but I do have the knack for working with people, so I'm going to focus on that first in whatever challenges lie ahead.

I'm going to tell you here about my product's recent release to PROD. It was a success because I had the support I needed from the right people. And it could very well serve as a summary for what the life of a PM is like. This summary is sort of an "Ikigai" of this role : the balance between what you know how to do, what you want to do and what you think will be good for the world (Thanks, Simplon!). So here's your PM-kit for planning an important change done by your team, alright? It comes in the form of a magical list of 10, to give the satisfaction of squeezing just another piece of structured info into your hectic day!

1. Plan, plan and unplan! Connect with the key persons long in advance and assess the impacted systems. Be aware of the current critical path your company is focusing on.

Whatever hunch you have about a certain system or unchecked detail, get it reviewed. It will most likely become your biggest problem or stop you in the middle of things. Always make sure you involve everyone who could be affected and give them plenty of time to add that to their backlog.

Prioritize and review those priorities as you go. Then be prepared to only get your best idea right before the deadline! Or implement the exact opposite of what you planned. In other words, stay agile! (I know my boss was close to a heart attack just now).

2. Be considerate about other teams' backlog and ask them what it takes to have their support. Be passionate when you present the situation to them. They will only become your ally if you trust the process yourself. Make them commit to your cause.

3. Communicate, communicate and communicate again. Send an announcement when you start, when you're successful, when you fail (ideally with a solution or the ETA). And when you've reached with a milestone, send a message again. Tell outsiders what the milestones are and provide an estimated date for that. Ensure you use the right channels for the right audience when sending out communications. Emails, Skype, Lync, Slack, snail mail (just kidding on that last one).

3. Know your people. Do you work with very risk averse persons? Show them extra care and every now and then, check that they are still on board. They will easily turn into people that go that extra mile. Do you have people that can't wait for the thrill of a crisis? Make them your main men and most treasured advisers.

And remember: don't ignore your stakeholders! Build a stakeholder matrix, a picture board or whatever it is you prefer, to map their influence and importance. Then think of a strategy for approaching each of them. Show that to your team!

So know your people! Then learn from them. Everyone you collaborate with has a valuable lesson in store for you.

4. Never ignore the technical part of what your project is about. You may not be the developer or the architect, but you need to understand dependencies yourself, flows, faults and advantages. Divide and conquer: break down your system into components and keep it simple. But make sure you learn as much as possible and always grasp the wider context.

5. Be present and be realistic. Which is to say: remember that a job like this one requires you to learn a lot on the fly. There will be very little time to resume, revert or review your lessons. Learn things on the spot! Make connections as you hear about new details and don't kid yourself about bookmarking an article you've never finished reading. The world is packed with useful new info and you're only human.

6. Always talk to your users (your final users or a focus group): inform them, involve them, explain things to them and convince them to see the value that you see in your project. Put yourself in their shoes when planning and allow them to contribute to improving the app. Carefully observe them when they are using the system/app to fine tune the product. If they are close to you, go and talk to them directly. You need to get your legs stretched during the day, don't you?

Send newsletters to keep them posted and brag about your team's achievements. Not the Trump kind of bragging, but in the bold, personal and creative-kinda way. Use informal but also professional language to deliver news to them. No one likes reading emails and certainly not the dull and unengaging ones.

Send them surveys to see how well your product does. You can't possibly reach all users, but every PM has gone through the satisfaction of picking the right polling tool, building a survey and the thrills of waiting for the results.

7. Be the first and most exigent user of the features your team is building. Hold frequent demos with your developers and test the system yourself. I have one great QA now, so I often notice bugs he has already logged. But I'm just lucky- let's be honest that's not how things work in IT.

8. Visualization is key! Make diagrams, weird-looking drawings in Paint, advanced diagrams in VISIO, or timelines in PowerPoint. Publish Gantt charts. Use Excel for listing steps in a plan. Then put all of these in a shared location and test whatever you send: does the link work? Does everyone have access? Does it look good? Is it concise and clear enough, would you read it yourself?

Make visual representations of how things work so you and everyone in the business dept. can understand it. Use pen and paper every time! Don't enter a meeting room without a board. If need be, draw on the glass walls (just please make sure it wipes off and the marker is not a permanent one ;).

9. Back up everything, with data. Get a DBA to run queries in the DB to validate assumptions, eliminate rare use cases and get the 20% that does 80% of the work. Or if lucky enough to have DB permissions, run the query yourself.

Teach yourself some SQL to get the results you need. Then learn some Excel tricks: pivots, formulas and graphs. You need to be able to nicely wrap the info you're delivering.

And always offer statistics: before, during and after a release. Demonstrate the added value of whatever you do, with data. Make friends in the Business Intelligence team and collaborate with them on getting the reports you need. Make them aware of how important their team is for you (hint: one good ice breaker is casually exchanging tips for holiday destinations).

10. Keep your team engaged and support them. I should have started with this one, I know… That is because your development team is your means of getting great things done. Understand them, be their friend. Don't wear them out. Plan things based on their bandwidth, not on the calendar days available. Shape the product together.

When things get complicated, make sure they are all happy with the situation. Support them in any way you can. I for one really recommend bringing treats to work, or preparing them on the spot, with your team. Even with the risk of setting off the fire alarm! Well that last point, made me reeeeeally hungry, so I have to end this.

That was my take on PM'ing. For now…I still have a few ideas and I myself still have some work to do on the points above. So what do all these 10 points make a PM? The facilitator, the SME, the people manager, the designer? You tell me. And cheers to whomever managed to read this through! All questions are welcome. I'm curious how many others of you out there can relate to this and can also share their experiences as product managers. I'll be here waiting and learning.

[1] When we schedule things, we don't want to just show up, we want to be effective when we get there. This means we need to manage bandwidth and not just manage time.

PS: for those in VE to whom I promised documenting this recent PROD switch, I will do a write-up soon. Right after I'm done with these muffins for Monday's planning session!

Camelia Gui
Camelia Gui
Product manager