Being a Product Manager with a Product in-progress

Choong
4 min readMar 12, 2020

--

With a non-conventional background in the creative and tech industry, I created a product manager job for myself back in 2016 with Radica Software, which at that time was developing a new product called Vecta.io

Taking on a product in-progress as a first time product manager feels very much like navigating in an open water. Given the almost full freedom and independence to steer the ship, I choose to focus on the several things below:

1. Carving the Product Vision out of the CEO’s mind

With a technical founding team, the product vision at the time could feel like an orchestra of product features.

To bring better clarity to the product vision, I made it a point to have conversations with the team and Tom to figure out what they think they are building towards. It should come at no surprise when there are conflicting answers — it’s a product manager’s job to pull together the V1 vision for the product and put them in words, backed by both company insights and technical works in the roadmap.

A product vision is a living artefact that evolves as the team gives the product more thoughts. It was these critical thinking and questioning of the product vision by my fellow colleagues that bring solidness to the product vision as time goes.

The product vision also serves as a foundation to our marketing effort and content creation as we chart towards beta and later a public launching.

What could have been done better:

Better control of unnecessary vision steering, often towards places that we shouldn’t have simply because we technically can.

2. Creating the foundational UI and UX that scale

One of the challenges to create a graphical drawing tool is that there are not much reference you could look at. Most of the drawing and drafting programs in the market are clunky with outdated user interface design.

That said, creating an all-new interface was out of question and impractical. This is because most graphic software users are accustomed to a certain UI standard on where things are and how things work.

Forcing user to learn to use your software from scratch is NEVER a good idea. As we develop the user interface and experience, I worked closely with Tom to make sure certain aspects are taken into consideration:

  • UX Scaleability: To ensure future features addition would create minimal disruption for both our users and our frontend dev. One example is also the constant struggle to use icon only OR text only OR icon+text.
  • User Success: Vecta is a collaborative graphical drawing tools. From early on, we recognise the importance of making it extremely easy for users to create drawing and share with their team with minimal clicks. This thinking guides our team to develop with user success in mind.
  • Hierarchy of UI: I’d defined that as how features are presented to users in the UI based on their importance to users. For engineers, it is tempting to take UI hierarchy as an after thought, and move on to develop the next feature. Without paying attention to details like this could lead to important features being overlooked and inaccessible, even though they exist on the screen.
Different vecta dashboard designs that we have created

3. Culture and Communication

I am a big (read: HUGE) believer of company success is driven by great company culture. Communication is key and people should feel comfortable to take risk and learn from mistake.

I advocate open discussion and have spent much time facilitating conversations to iron out decisions and emotions that could have accumulated to something worse. The challenge here is always that discussion and meeting are often seen as a waste of time(and I agreed half of the time), it is always easier to just overlook human emotion and code away. The few times I decided to do that, it always end up coming back to haunt the team when everyone realized they have been working on the opposite end of each other.

Even so, I recognize the importance of deep working time and I trust charting between if a meeting is needed would be an on-going struggle for my product manager journey.

4. Processes and Collaboration

In the later days, I started experimenting with the Scrum development framework. My lack of experience in practicality makes it a hard case to convince the team to come onboard, and the first few sessions were filled with awkwardness — but nonetheless we manage to kick it off.

Personally, I believe the SCRUM framework is a living framework that should be customized to the need of the team. With this in mind, the team has tried on multiple renditions including daily standup to weekly standup, a rotating scrum master and more.

I considered myself having hit a milestone when the team initiate the standup independently and started asking questions regardless of seniority. There are countless more such occurrences since then :)

Being a product manager for a product in-progress could feel like a slow journey. Only by looking back could one realize how far you have gone.

I am on the lookout for remote product manger opportunities. If you are:

  • Looking for a remote product manager
  • Or a product manager that has something to share

I’d love to have a chat. Do ping me at choong.brick@gmail.com

--

--

Choong

Pursuing location-independence with an interest in product management, UX, growth and org culture.