Return to site

Product Management & How It Works for a Tech Startup in Malaysia

PM Thoughts & Life | Malaysia | Local Tech Startup | <25 employees

What is product management?

What exactly do you do as a product manager?

These are the common questions I received over the years, it was also a question that I asked a lot to other experienced product experts.

Short Answer:

  • Product management is the practice of strategically driving the development, market launch, and continual support and improvement of a company’s products. - ProductPlan
  • Product managers are responsible for guiding the success of a product and leading the cross-functional team that is responsible for improving it. It is an important organizational role (especially in technology companies) that sets the strategy, roadmap, and feature definition for a product or product line.  - Aha!

Long Answer: this article

After researching, talking with product managers and involving in product management for some time, it is safe for me to conclude that the role and scope of a product manager can be very diverse, there is no one perfect definition to describe.

You can find many good 'Product Management' definitions using Google search. In this article, we will look at some common ideas that I personally learned, and share my daily activities as product manager in the context of a tech startup in Malaysia.

Some phrases you might heard about product manager:

  • Often known as "the guy who is responsible for product strategy and roadmap". It sounds simple but it can involve very complex works.
  • Constantly making alignment between different teams in an organization, typically Business and Technology, and sometimes Design. 
  • Crisis negotiator, mini CEO, the guardian of the backlog, Jack of all trades, master communicator, product visionary, voice of customer, owner of problems
  • "So you are a project manager.."  No! okay, maybe.. 
  • "Everyone in the company hates product manager" , "No one likes product manager" ouch!
  • It is common that product managers deal more with people than product.

Examples of Question that PM often need to attend:

  • Finance: can we implement and introduce this new pricing model with the product?
  • Sales/Customer Support: can we add this new feature that requested by a user?
  • Developer: can we do this if it helps to optimize business value and but with cost of technical debt?
  • Designer: can we try this new design to shorten the user journey?

PM as a middle man should work together with them to answer all these questions holistically. Often, start by asking 'why (do we need that)' and before saying 'how (we can achieve is..)'.

In the tech industry, it is common for a product manager to involve in the following:

  • Gathering product feedback/requirements from different business teams
  • Working with designers to ideate new product feature and design
  • Discussing technical feasibility and task planning with tech teams
  • Reporting on product updates with all relevant teams

Above are the typical responsibilities of a product manager, these resolve a lot on working with different groups of people. I once heard this statement of "a good product manager should not be doing any actual design or coding work". It seems true, especially for PM in a larger organization. When it comes to working with a smaller organization or startup, it can be a total different case. Some PMs even assume marketing, and P/L responsibilities. CEO of younger startup sometimes fills the PM role by herself too.

PM in different sizes of organization:

  • Big (Google/Facebook): Few PMs to work on 1 product feature. This is common.
  • Mid (50-250 employees): 1 PM may focus on 1 single feature, or even a subset of a feature. 
  • Small (<50 employees): 1 PM may focus on 1 product or even few product lines. 

When I first started to get involve in product management, I researched online and spoke with different experienced product managers. Undoubtedly, everyone is using different method and has their own way of managing product. I've also seen bigger organization using very simple tool like Trello, as well as smaller team using paid tool like Jira to manage product projects.

“It is never about which method, process or tool that works best, but which one suits your team the most”

In a smaller organization setup, you might need to involve in almost all aspects of a business. Unlike bigger organization that usually spend enormous time on planning and meetings, a PM in a smaller startup often has to focus a lot more on execution.

For you to get the idea, I try to list down the typical works for me as product manager, and split them into different phases: Discovery / Planning / Execution / Others

A) Discovery

  • Problem Research / Diagnose:
    • Internal: Team feedback, Sales data, Customer Logs, Azure Application insight
    • External: Interviews, Google Search, Google Trends
  • Stakeholder review: gathering feedback
    • Internal: sales, marketing, finance, operation, customer teams
    • External: existing users, past clients, potential customers
Quick Tips in performing external research:
  • Use Google Advanced Search, and set to show 100 result/page
  • Use disposal email service like Mailinator and SharkLasers

B) Planning

  • Business Diligence with different business units, to ensure solving right problem and justify business value
  • Technical Diligence with tech lead and developers, on technical feasibility [does it work well with existing structure?]
  • Daily Standup with product team (developers, designers and PM)
  • Task Management [Tools: Asana, Trello]
    1. User Stories: everyone who read it should understand who is having what problem/need and why it matters to the user. It lays the groundwork for us to identify how we might solve it, and why we solve it that way.
    2. Backlog Grooming: this is one of the parts where "everyone hates PM", because PM has to decide what goes into backlog by rejecting/deferring certain requests from teams.
    3. Prioritization: "highest business impact, least resource required" features should always go (ship) first, duh! Easier said than done.
    4. Roadmap Update: timeline and sprint planning
    5. Task assignment with tech lead and developers
    6. Repeat (Update/Refine)

You will always have TOO MANY THINGS to build, but with limited time and resources.

If you wish to deep dive into product roadmap, here's a good video (28min):

Product Roadmap steps proposed by C. Todd Lombardo

☝️ Product Roadmap steps proposed by C. Todd Lombardo

  1. Gather inputs
  2. Organize & prioritize
  3. Roadmaping (timeframe)
  4. Sprint/release plan

All these steps can be done by using tools like Asana/Trello, and we coupled with spreadsheet to plan on the timeline and release plan.

Tips:

As a UX-consultant-and-marketer turned PM (non-programmer), I am not competent to justify the time required for building a feature. However, having gone through several online programming classes and offline coding bootcamp, it helps me to communicate and work better with developers. It is good to know some technical Jargons, than needing the tech team to make explanations all the time. The later is a product manager that developers might not happy to work with. Personally, it also helps me to empathize developers after having tough time in picking up programming.

A programmer-turned PM (or Technical PM) usually has unfair advantage when it comes to technical task planning, without completely relying on tech lead or developers to gauge task effort.

No matter what type of PM you are, you need to have good people skill to connect different stakeholders from business team, tech developers to end users.

C) Execution

  • UX Design Review with designer and relevant stakeholders
    • Striking balance between several aspects, e.g. business value (conversion, SEO), UX, and technical challenges.
  • Flowchart to facilitate discussion and product planning. It helps to identify possible user journey flow and helps to make better evaluation [Tools: Microsoft Visio, Draw.io, LucidChart]
  • User journey flow: mapping out the steps require for users to perform a task
  • Wireframing/Prototyping for ideation and gain feedback from stakeholders    [Tools: Axure, Adobe XD, Figma]
  • UAT (User Acceptance Test) plan drafting for staging and production
  • User Research: testing and feedback with clients or potential users.
  • Analytics tracking plan, identify metrics to success of new release
  • Business Reporting to relevant stakeholders
  • Knowledge management: documenting important data records, research outcome, business reports, wireframe records, useful references

Tips:

The job is not done after a feature goes live. We need to further justify whether the new release is success or not. This can be done by looking at analytics data, business result, and user feedback.

Junior PM and Designers: Myopia

Most people and designers are good in improving the interface of a specific page. e.g. 'this button is causing confusion in this page, let's just remove it from this page!', but that often creates more issues to other parts of the product and lead to more problems. Hence, I love to get them to work on user flowchart since the beginning, and have them review the whole flow thoroughly, even when we only receive a small change request on certain part of the product.

By evaluating the whole flow from beginning to the end, we are able to get better overview. In many cases, we would be able to pick up many problems that we might missed and even uncover opportunities for better improvement.

D) Others

These are the tasks that more likely to occur within a smaller organization, that many people perceived as 'not the task that PM should do':

  • Technical research: Stakeoverflow, documentation reading, inspect element
  • Tools Research / Optimization (cost & value analysis)
  • Stakeholder workshop: whiteboard and sticky notes~
  • Marketing research: Industry Trend, Competitor Benchmark
  • Digital Marketing: SEO, email, Faceook and Google Ads, etc
  • Graphic Design for marketing and instruction guides
  • Coding: minimal coding with Google Tag Managers, setting up conversion pixels etc.
  • Business Development: Skype call with potential partners, to discuss business model, product integration, and learning
  • Data Analytics: conduct data analysis and/or build data reporting framework to democratize data practice [Tools: Google Data Studio, Power BI, Power Query, Excel]
  • A/B testing experiment  [Google Optimize]
  • HR: Appraisal, Recruitment, Training (internal/external)
  • 1-on-1 meeting with team to review performance
  • Training (self-conduct):
    • PM-train-PM: e.g. designer-turned PM, and programmer-turned-PM (Technical PM)
    • Specific niche: from Digital Marketing to Marketing Team, A/B testing concept to developers, to Email writing crash course for interns
    • Team performance: e.g. provide actual case studies to educate junior programmers on the importance of clean code, that it might not affect just programming collaboration but can have negative impact on business and marketing (analytics configuration) sides too. 

Final Thought (Good vs Bad PMs)

I have provided quite a number of daily PM activities in a smaller tech startup company. If you're interested to learn about the comparison with big companies like Google, you may take a look at this slide. After going through the content above, you probably realize that PM's job is closely associated with UX design, you may also check my article to learn more about UX Design for Business.

Here's a no-bullshit article that talks about the difference between Good & Bad PMs (written 20 years ago and still gold), and these are 2 good points that I think many neglected:

  • Good PMs focus the team on revenue and customers, not number of features built
  • Good PMs create leveragable collateral, FAQs, presentations, white papers

"NO" from PM

At the beginning of this article, we mentioned "everyone hates PM". It is very tough to make everyone happy, unless you're selling ice-cream. Different business units may request for different features or fixes that are important to respective departments, and PM has to decide which one to do first, which one to keep in view, and which one to reject. Such decision making is hard to get 100% satisfaction from everyone.

The PM's job is to say NO, and not to say NO.

As the 'guardian of the backlog', PM says 'NO' to defend the backlog, as well as overall business interest. It is essential for everyone to understand this and buy in. I always remind new PM that 'our job is to say NO, and not to say NO'.

  • Having 'say No' mindset is a way to challenge PM to think forward to uncover truth. Instead of receiving a feature request and implement it right away, PM should ask good questions and acknowledge that "there are always more than 1 way to solve a problem"
  • PM never reject for the sake of reject, but to make data-informed decision, and most importantly to communicate it with relevant stakeholders​. In God we trust, everyone must bring data.

PM's life is much easier, when there's a strong open team culture in the company.

Good PMs provide "single source of truth" to connect teams

It is uneasy to facilitate communication and effective understanding with diverse groups of people. This can be enhanced with proper flowchart, wireframing, documentation, and reporting.

Unlike big organization that can afford a paid enterprise suite that can does almost every aspect of product management and to get an overview very easily, a smaller startup team usually use a combination of different free tools. It is essential to have a strong internal Wiki, to record and update important document links/records at one place. If you ever face challenge in finding a internal document or getting good overview of the product planning, then you need to work on a single source of truth.

Good PMs are explorers that conduct test experiment

If something can be tested out quickly to get feedback/data, then PM should try to facilitate that before implementing the full fledged feature that can take much bigger resources.

E.g. spend 1 day to build a simple rating feature, test with closed users or even live users. Based on the test outcome (sometimes to prove that it works technically), then proceed to implement full feature that might take a week or more to complete.

Good PMs seek to understand the reasons behind feature request, make good evaluation with teams and propose effective solutions. Great PMs influences everyone to think that way, makes it a common practice and thought process across the organization.

Thank you for reading

I might not be completely right with what I've shared above, I still have a lot to learn and hope to share more in the future. I hope you now have better idea to the questions: what is Product Management and what exactly do product managers do.

If you think Product Manager is awesome and underrated, tell them when you meet one next time!

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OK