Seeking Happiness in Product Management? Start Coding!

Part 1


By Shabbir Khan

Let’s say that you’ve been doing product management most of your life. You were successful in progressing from a junior level position to a pretty senior position in product management at a large public company after years of hard work. You’ve become a domain expert in more than one technologies.

You’ve mastered the art of keeping your sales and field engineers happy.

Engineers in your product teams respect you because you know so much about the latest technologies and your product roadmaps. You also read their source code every night to stay on top of their progress without telling them about it.

Marketing is happy because you help them craft the most effective positioning statements to keep your products differentiated from the competition.

Managers are happy because you are good at producing solid PRDs (product requirements documents) and delivering release after release like clockwork. CFO loves your pricing strategies because you’ve been using the latest research in behavioral economics for pricing your products.

You control your cost of goods sold (COGS) like a hawk. Your products meet the profit margin goals that are consistent with your company’s business model. Everybody in the company is happy with your performance.

Everything was going great for you till you foolishly accept a job offering you a VP Product Management position at a software startup targeting millions of end-users.

You were never ready for the new painful reality — reality of working for an underfunded startup that doesn’t know when it will be able to raise its next round of funding. It is a SaaS company with a dubious customer lifetime value (LTV). You suddenly find yourself living in the belly of a beast.

Company doesn’t have the money to hire a design engineer to give you the user experience you are looking for. It doesn’t have the money to attract more experienced engineers who can build a large-scale cloud app.

Your front-end engineers have been using an outdated framework (MVC) for building traditional apps in C# using .Net or C++ for a Microsoft Windows platform. Couple of engineers have built small web sites using HTML, CSS, and JavaScript. There are some engineers who have built mobile apps in Objective-C but nothing that can scale up to handle millions of users.

Your backend engineers are real good at coding PHP and J2EE servlets accessing traditional SQL databases. Although your engineering team is excited about developing a cloud-based application (using a NoSQL database), nobody has produced and deployed a real product in the cloud.

You also discover that although you can deliver most of your product’s functionality in a browser, there is a critical part of the app that could only run in a native mode. Now you are worried about supporting a large variety of devices — all with different screen sizes.

“This is a job from hell”, you start saying to yourself. You wake up in the middle of the night dreading your next day at work. All you can see is that you’ll be wasting another day convincing your engineers to adopt a full-stack application mindset for scalability, security, and performance in the cloud. You are worried about your next meeting with the CEO because you don’t have a good answer about your product’s delivery date.
I was faced with a similar situation at the last startup I was a part of. It was pretty painful till one day I told myself, “quit this job or start coding yourself and lead the engineering team to develop this product”.

I used to program before moving into product management but that was many years ago. Let me chronicle how I was able to change the situation and reclaim my happiness as a product manager.

Ready to get hit by a cocktail shaker?

I immediately called a friend who used to work for Google. We went to a local Starbucks. He listened to my problems. I described the new application stack I had in mind for deploying in the cloud. He liked it but warned me that I’ll be confronting a bigger issue. If I make any change in the front-end, it has the potential to percolate all the way to the backend. And if I change anything in the backend, it will cause a ripple effect all the way to the front-end.

“It will be like getting hit with a cocktail shaker”, he told me with a big smile on his face while shaking an imaginary cocktail shaker in his hands.

I decided to minimize the cocktail shaker effect. I thought I’ll be able to tame this beast if I could make my front-end and backed engineering teams agree upon a RESTful API for the entire product before they start doing any coding.

I was confident because I had a very clear vision of what the product was supposed to do. I knew what functionality our customers were looking for in the user interface. I had it all in my head so I started calling all hands engineering team meetings to explain what was in my head.

Learning to design a RESTful API is relatively easy. Luckily, there are plenty of sites on the Internet for teaching you how to design a RESTful API. All you’ve to do is to google using the key words, e.g., design a RESTful api.

Before I knew it, I was talking a language that included verbs (GET, POST, PUT, PATCH, DELETE), nouns (e.g., users, contacts, messages, notifications), and filtering, sorting, and searching of results.

A new disaster hits me !

Getting an agreement on the need for a RESTful API for the entire product was easier but achieving that goal proved much harder. Nobody could agree on anything and our RESTful API team meetings started degenerating in chaos without any end in sight.

I stopped holding RESTful API meetings with all of the engineers in the same room.

I started pairing up only one front-end engineer with one backend engineer making them responsible for designing the RESTful APIs for only one microservice at a time. I started holding shorter meetings with each pair of engineers focused only on an individual microservice.

It worked. Before we knew it, we had the whole RESTful API done. I told everybody if they wanted any changes to any of the microservices they should come to me.

We also standardized on using JSON for exchanging data between the frontend devices and backend servers. It is a widely used format in the industry. A word of advice: avoid using XML unless you are building a content management system or XML is the only thing you know.

I also started worrying about security in a public cloud. I had few experimental EC2 instances running in the AWS cloud. One month, for no apparent reason, I started seeing my Amazon bill going through the roof. I immediately called Amazon support and found out that my EC2 instances were sending a lot of outbound Internet traffic that I was not responsible for.

I was sure that none of my EC2 program were causing this traffic. It turned out that somebody was constantly probing my ports and hitting them with some random packets resulting in an outbound traffic that I was not expecting.

Lesson learnt. Security is important. First of all, there are lot of hackers out there who love to break into systems just for fun. There are non-state actors (including some of your competitors) who may be interested in knowing what you are doing. And let’s not forget the state-sponsored actors including the Chinese, Russians, British, and, of course, the NSA. They are all out there to get hold of your data if you are paying any attention to the revelations made by Edward Snowden and Julian Assange.

It was a good time to become lot more serious about security. I had no choice but to close all unnecessary ports, use TLS, deploy a virtual private cloud solution, and enforce stricter access controls on all assets.

I had started feeling a bit more confident with a RESTful API design in my hand. I thought that all of the engineers in my product team will become full-stack programmers soon. Rest of the implementation should be smooth.

Time to have a party and celebrate? It was too early to celebrate. My troubles had just started. Wait till you see Part 2.