That thing you (forget to) do part 3: Product management

Product management is probably the toughest of the trio, and that’s why I leave it to the last. The essential aspect of product management is to sew the threads of development and marketing with data measurement, customer feedback and team execution.

One of the most frequently asked questions from start-up founders is, “If there is conflict within the team on the direction of the product, how should we decide?” It’s actually not a tough question if the founders are analytical, logical and able to stomach their own egos and say, “Yes, this did not work and let’s try something else.”

Product management: The lean start-up and permanent beta

In the first article of the series, we stressed on the importance of planning and execution. We built on the existing framework of Eric Rees’ “The Lean Start-up” model, where we create a product using the agile methodology, gathering user data and feedback, and iterating to the next version of the product.

If we find that the feature of the product does not deliver, then we pivot to something else. The concept is intrinsically simple because the product is permanently beta and constantly evolving to the point where it can address almost 99% of customer needs. What people often don’t figure out is the actual implementation in practice.

I want to point out some challenges that founders face with their employees in Asia as compared to Silicon Valley. The first problem is attitude. Everyone has heard of the ideal Silicon Valley employee: Passionate, always ready to give and execute on ideas and put in 150% because his future is tied to the company.

In reality, many employees are far from that ideal.

Some engineers are afraid to speak up and even upon being encouraged to do so, got scared when being challenged. The worst part is that they have an employee attitude in that they only work from 9am to 6pm. Most people are aware of these problems and have encountered them. You probably can’t change their attitudes overnight, but everyone can take a step to nudge them in the right direction.

This problem has everything to do with product management because the project is affected when founders can’t convey their vision and mission to the employees and excite them to do something that means everything.

Here’s a way to induce agile development slowly in a typical Asian setup. First, let the engineers plan a small feature that they are going to build. Be the critic and bring up different issues that might affect the feature. Remember that the product managers has to oversee every aspect of the product, and dealing with loose ends is pretty important.

In fact, one understated problem I’ve observed that is frequently encountered by software engineers is the backend infrastructure which often does not scale with the growth of the product. Usually, costs and time is the issue. Most technology people do not convey the technical debt or express the latent business costs that comes later.

As a result, these issues get ignored by the management (and the same problem happens in a lot for big Asian companies too). It will spiral into bigger problems and the technical guy telling the business guy (be it founder or employees), “I told you so.”

Second, in an agile framework, the developers of the product: Software engineers, frontend developers and builders are sprinting while the product manager is running a marathon. What usually happens is that people want to do this too quickly.

It takes a team at least four to five cycles of development to really have the kind of intuition and insight about infrastructure. Hence anyone thinking that agile development behaviour can be learnt within two to three cycles are dreaming.

To build a good hacker culture requires time and space. It reminds of something that I often ask myself: Why can I achieve a high level of productivity in the Sanger Institute (which is my ideal workplace) more easily than compared to Singapore?

My answer is culture and people. If there is no empowerment in the culture, the company’s burden will only be shared by the two founders even in a 20-person team. If you make the environment horrible for your employees, you should not complain when things are not moving.

One other thing you might want to do is to constantly find interesting things you see from other companies out there, and ask how they can be done if it’s your company. It might allow you to take best practices and also understand the thinking processes of your team.

Constructing the Killer Metrics from Data

Product managers need to find metrics from the data they measured. There are two types of metrics and most product managers in Asia do the first but not the second.

The first metric is a vanity metric, which comes in the form of user downloads, user registrations, and users inviting friends to the app or web service. The second is the killer metric, which centers on how users are constantly using your app or web service, and how they might evolve new social practices.

It’s easier to illustrate with an example. The retweet feature in Twitter started off as a social practice, where influencers and tastemakers share insights from people they think are interesting. Eventually, it is used to measure how influential a Twitter user is.

A killer metric should lead to two things: (a) how viral your web service or app can be and (b) how you might convert a social practice into a feature to increase user engagement with the product. There are differences in consumer-facing and enterprises apps but both converge in terms of usage patterns and analytics you can derive from user behaviour.

If your service seems to work with one group of people and not another, you might want to figure out why that is the case. Someone asked me, “How many people should you gather feedback from?” The answer is as many as you can get.

But do you listen to all customer feedback? The answer varies.

Managing customer feedback can be challenging, but the way to do it is to break their feedback into three types: (a) Useful and informative and you can see immediate ways to merge their feedback with a small tweak in your product features, (b) a small nuance that provides you some ideas for the future but not now, (c) blue sky and totally irrelevant.

Here’s something I have noticed when a start-up goes to an organization to do product demos. They are two groups of people: (a) the ones who wants to champion your technology and help to grow your product and (b) the ones who will shoot you down and think that they are smarter than you in developing the product.

The key to deciding which feedback to adopt is to classify internally with the team what is sensible and what is not. In fact, only in start-ups, the sales people are much more connected to the technology team than in bigger organizations but the problem often lies in communication.

Bringing it together: The roadmap, media plan and data analysis

If you are a product manager, take a spreadsheet and draw up a plan that integrates the product features, content and help roadmap (managed by software engineers and designers), the product marketing (manage by sales, marketing and business development people), and the data analysis (which is likely to be the founder).

Then share the plan with everyone with explicit timeline and milestones. You should get some feedback to see if the deadlines are realistic, and spend a day reviewing this with every team. With this process, your life will be so much easier when you press the execution button. Everything will be set in motion.

Of course, no product manager is perfect, and we often learn from our mistakes. The last thing I want to emphasize is that a successful product involves people and resources. While in Asia, given the cheaper costs that comes with technology arbitrage, we don’t deem people to be important.

However, growing people to be part of the company is important to achieve real success. Whether you are going to build the best product or not, depends upon planning and team execution. Both processes requires people.

If there are days where you feel like nothing is working, you should probably ask the question, “Once upon a time, the most successful companies of today started like us, why did they scale and why aren’t we doing the same?”

References:
[1] FrameThink: The Four Viral App Objectives (a.k.a., “Social network application virality 101?).
[2] Eric Rees, Startup Lessons Learned.