Software Product Management in Hong Kong Startups
What is a product manager responsible for?
PM is the centralised point for whole team, not only involving development work and most important — bringing the vision into the team and archive it together!
What documentation tool you use to prepare user flow, features and task arrangement to whole team?
Trello and JIRA.
With regards to projects which involve both hardware and software — how do I implement Agile methodology to this kind of ? (Agile product management is too fast for hardware, but waterfall is too slow for software)
Although hardware is another world, but still PM also has to take time to learn for different experts and turn into your own knowledge. Hardware development is waterfall to me, once they start the development process, you can hardly change it. But still the most important aspect is communication.
Better consolidation in all the requirement/situation you know before starting the hardware development. Once the development gets started, better keep communication between both hardware and software team. Somehow we may need the software team to cover the hardware limitation.
As a PM, communication and preparation is important. Three main activities: Communicate with your user, visualise your vision, draft the product plan. For example, brainstorm meeting for gathering requirement, technical meeting for feasibility etc.
How to use Jira?
When we use Jira, we need to set convention alongside with it. The role of decision maker is crucial, like who decides and when to add backlog items. We only set authority for PM and business people to move backlog for development for the week during the Monday’s project catch up. So even though we have tools that help us keep track of the progress, at the end, the PM has to be there to ensure everyone is using it the same way.
How can a PM better himself?
Learn more and read blogs on PM. e.g. Intercom. Also try to learn more about other products through channels like Medium. Expose to more fields, be it UX/UI, marketing, operation, sales. I personally like read psychology and somehow UX stems from psychology. A broad knowledge base gives a PM the ability to understand the product from different perspective.
Ultimately PM is target-oriented. PM have to use resources effectively to achieve the goal, which is product success. PM’s view are better to be all-rounded, if PM lacks knowledge in certain areas, the blind spots may be costly.
Can people without a technical background also become a PM?
A technical background is always a plus, for example when reading API doc. A technical background also gives you a different point of view towards your project.
On the contrary, a non-technical PM usually has a better communication skills. A technical background PM is super logical yet sometimes maybe too rigid to deal with new situations. For a non-technical PM, maybe the hardest thing is how to understand and communicate with developers. Therefore it is beneficial for non-technical PM to understand basic programming, even concepts as basic as if-else statement. But ultimately technology is a tool, for every PM, your product is all about how to present the product idea using this tool.
How to balance the team and keep up with the schedule while on one hand you have to debug and on the other hand you have to add in new features?
Scrum team as a team must handle all stages of the product development. A scrum Master must look at the velocity of the team.
In a normal scrum, there is a planning session, daily standup meeting, retrospective. Traditional software teams give estimates in a time format: days, weeks, months. Many agile teams have transitioned from time units to story points. Story point in general refers to the effort / difficulty of the task/feature, decided by the team together.
No matter it is Quality Assurance tasks like debugging or development tasks, we estimate the story points and make flexible arrangements as to manpower based on the estimation. We follow up the story points at the retrospective meeting and therefore can better understand the velocity thus the performance of the scrum team. From my experience, it may take 3 sprints to understand the scrum team and its velocity.
Retrospective meeting also provides insights on how the team achieves the current velocity, whether the team members are working overtime or their capacities are not yet fully utilized. Also in this meeting, Scrum Master can understand what are the bottlenecks of the project and the good points.
A Scrum Master shall understand how each backlog item will affect the overall schedule based on experience. Each backlog item will also have an impact on different parties to the project. And it is up to the Scrum Master to decide how to balance the interest of each party.
I gained all my product management skills from these two startups. I learned how to observe data and identify what users love and what users don’t love.
Data is important for a PM, but also I learned how to receive comments from different parties, i.e. While I was still working with Gogovan, occasionally I spent some time to be a Customer service officer, through this experience I learnt more on the pain points of the drivers, customers and the customer service officer. These kinds of inputs can never be extracted from data.