Most of my life, I had the title “analyst”, but I don’t think I was ever an analyst. I was just good at understanding and fixing the flow of data.
I also wasn’t a great data visualizer. Maybe “data visionary” is a better description of my skills.
For the past few years, I worked with a lot of engineers, and I learned quite a bit. The following is a list of things I’ve learned, and I hope it will help you in the long run too.
Plan ahead
We all tend to live in the now and put out fires later, but a solid plan at the beginning of the quarter can reduce the fires. Not only that, but having a clear vision will help organize tasks and ensure your product is steered in the right direction.
Write it down
I often tasked a developer without creating a ticket, and it’s no surpise the end result wasn’t what I requested. It wasn’t because he was bad at his job. I just didn’t take the time to think about what I wanted thoroughly. Writing down tasks forces you to think, and when the time comes, you’ll be able to better explain what you need.
Less is more
When writing tickets, think small. Stick to the vision and the product requirements, but don’t tackle all your problems at once. Solving one problem at a time will ensure the best solution is made.
Create a product-oriented team
When you’re not focused on a product, you tend to do jobs you prefer. Engineers are the same. If they can work on something else, they will. To avoid this, structure your team around a product to ensure all functions are committed to the tasks ahead. Doing so will ensure everyone focuses on the tasks ahead.
Product backlog
We tend to think transparency only works in one direction, but we forget developers need transparency as well. Creating a backlog of tasks will facilitate planning and allow you to easily pivot from tasks if they’re not ready to be worked on.
One task manager
When more than one person sets tasks, things can get confusing. Make sure to designate only one person for assigning tasks. If anyone interrupts, make sure to explain this isn’t their place, even if it’s your boss and you think he knows best. Giving control to others means more confusion and slower work. Keep one person in charge to ensure fast working flow.
Sit next to your developer but don’t interrupt him
Are you on fire? No? Then there’s no reason to interrupt your developer. Check in at regular intervals like once a day or three times a week. But during his work day, interrupt him as little as you can. Allow him to focus on his tasks. Don’t change tasks on him just because you discovered it was wrong afterwards. It’ll just frustrate him more.
Developers don’t understand marketing
You have a great marketing idea, and you’d like him to develop some KPI related product. Make sure he actually understands what you mean when you say “MAUs”. Avoid being vague with definitions such as “MAUs are Monthly Active Users”. Instead, try saying “MAUs are defined as a unique user in a period of 30 days that access in the same country.”Why? Because the internet is full of MUA definitions. Don’t let the internet lead your product in the wrong direction.
I know it’s a lot to take in, but these seven rules will save you a lot of time in defining, driving and managing your next project more efficiently.
It did take me a while to learn everything, and even today I make small mistakes from time to time. But overall, I try to stick to the rules above.
