As I mentioned here, I’m taking a break from office life. But now I’m currently building a new product with a new team. I’m currently supervising 2 teams. One is directly managed, another one just advising. Both are related, a content or media platform to help help users discover and consume the contents.

It’s still new, we just started a couple of months ago, and it’s not long enough to fully understand which level our team, how good they are, and how good the outcome could be. But it’s long enough for early observation to know what we should improve and the current issue we have. This post is to document what I found in the last couple of months and what we should work on as a team.

TEAM A, the super early-stage product team

As an early-stage product team, the first one that I directly manage doesn’t have a product manager, only engineers. I’m the acting product manager, and I’m not a good product manager, especially to say no to a feature :D. I need someone to help me say no to the new feature and ship. This is really hard as an idea thinker like me. But we don’t have it now, so this is my take as a mediocre product manager.

• focus and prioritization. To deliver an MVP, sometimes it’s hard to focus on what we want to ship, especially when you keep finding a better function and keep spending time in iterations to enhance the features. Especially for me, I need to stop thinking about a new idea and ship it to validate it.
• documentation, not all engineers like to write and describe theirs idea or problems in a document. They prefer to speak about it in a meeting instead of writing it as clear as possible in a document. For sure, explain it verbally will be faster but not scaleable. As a remote-first team, scale the communication is the first thing to help everyone work in asynchronous. And documenting everything is fundamental of it. We need to keep asking everyone to write it in a document whenever they say it in a meeting.
• better issue and task management. We’re using Github for everything, documenting ideas, features, and bugs using Github issues. Slack is just a notification and a short discussion, but a bug doesn’t exist unless reported in Github. Not everyone really moves the card of things they’re currently working on in our Kanban board on our Github project. By improving this, we should able to monitor progress and estimate the timeline.
• Test and error notification need to improve. If you work in a team that works in the same codes, full-coverage testing will be needed to avoid someone overwriting a working code and breaking a function. To catch an error or exception as soon as possible, the engineer needs to be notified first before the user or other stakeholder notice it is something we need to work on.

That’s what I think we should work on first before talking about how we can ship faster. Facebook’s product development principle says move fast, break things. But what if those things that brokes are slowing you down? Then fix it first so we can run in a marathon faster.