Journal #1 - How Hiring a Product Manager is Enabling Scale

Last week, I said that I wanted to start writing about my non-Mealfarm biz. Well, here it is. This is how it’s going to work. I’m going to just write whatever comes to mind, reread it a couple of times, and then send it out! I’m not going to be writing topic-themed “articles” because it’s harder and not as much fun for me. My goal here is to help people and have fun at the same time. That’s why I’m calling it my Journal. It’s just my unfiltered thoughts.

Two weeks ago, I used TopTal to hire a part-time Product Manager. So far, he’s been an excellent addition to the team. One night I was laying in bed thinking about all of the problems my business was having and then I had a revelation—I need to hire a Product Manager!

For a while, this is how I would update my apps: Over the course of some weeks and months, I’d gather feedback from users via surveys, app reviews, and customer support and build out a list of features for an update. Then, I’d start building the update myself. I’d contract my designer when needed to design certain features or I’d improvise a bit. Working totally at my own pace, I’d get the build ready. Then, I’d send it to my QA tester and have him verify it’s working properly. Finally, I’d release it. This whole process might take a month or two, or maybe 6 weeks.

Then, when quarantine started around March/April, I decided that this system was pretty shit. It’s ok for a tiny app or a tiny company, but by this point, Hashtag Expert had grown beyond that. It had about 20k daily active users and 200k+ monthly active users. It’s a substantial user base and a lot of people rely on the app for their social media. I felt like I needed some more process.

So, I started acting like a product manager myself. I took one course in college about agile methodology and one of my good friends is a product manager at ESPN. I worked with him and another friend to learn a bit more about how they manage their development team.

I started creating “Sprints” and building out feature roadmaps in a very procedural way. I’d create a list of features, estimate the time they would take, and aim to ship a build every two weeks. I documented the whole process.

Digging down even further, every release would have a few key documents:

• a sprint document that outlines all the features and estimated story points

• a sprint review that highlights all the new features, points out areas for improvement, and lists key metrics to watch after release

• a post-release analysis that I’d make two weeks after release to evaluate the metrics I was supposed to watch

• a customer support brief that lists all the relevant changes for the customer support team

I really, really liked this system, but I ran into a problem that has been a recurring theme in my life—I did it for about a month and then stopped. After 5 sprints, I got tired. On top of managing and executing the sprints, I was doing a bunch of other crap for the business. Also, some weeks I get tired and don’t feel like coding. I want to take a break and just focus on my analytics or whatever. Do you see the problem? I was the single point of failure. If I wasn’t moving the entire ship forward, the ship wasn’t moving at all.

So I hired an engineering contractor. Surely this would solve all my problems. So the engineer started working for me 40 hours per week. He was really talented and I was paying him about $50/hour. We had some intro calls and I explained the various pieces of the app to him. At this point, I had basically zero documentation so he had to spend quite a bit of time just exploring the apps to fully understand them. Also, he had to navigate my bizarre design patterns. FYI, I’ve never had what one would consider a real job. Fortunately, I’ve been self-employed working on apps since I graduated from college. So I never learned how to code in an organization and how to write code that is easily understood by others. I build things my way.

The engineer was starting to do good work and things were getting up and running. It still required a lot of work from me. I had to coordinate with QA, approve PRs, and constantly give him things to do. Typically, when I want something done, I just build it the way I want it to work. That obviously doesn’t work with other developers. I need to carefully document and explain exactly how I want a feature to work and look. That’s very time-consuming.

Then one day out of the blue, the engineer tells me he wants me to triple his pay or else he’s going to take another contract. Shit. I tell him to take a hike and we’re back to square one, all that time I invested in helping him learn the codebase was instantly down the drain.

So, I decide to hire another engineer. With this one, I made it clear that I’m looking for a long-term engagement. He started working and was absolutely destroying all the tasks I gave him. But again, it’s still a ton of work for me. The whole point in hiring the engineer was to reduce my workload so I could focus on bigger picture things like what app are we building next and how do we triple our marketing spend. Some weeks would pass where I wouldn’t have any work for him so he started going deep into our bug list fixing whatever freaking bug he could find that QA reported. I was also somewhat distant for a couple of months. I was having some motivation issues with my apps. I wanted a change and something new. I was thinking of selling the app too.

Again, I was the single point of failure. The ship was at a standstill and I wasn’t fully utilizing my developer resources. That’s when my revelation came—I need a product manager!

I decided to go through TopTal because I wanted someone who was supremely qualified for the roll. Somebody who had worked at a big tech company who could institute the order and systems needed for me to scale this company. The truth is that I luckily have the cash flow to hire way more people. I can probably afford another 5 full-time contractor engineers, but I just don’t have the work for them right now. So in comes the product manager. It’s only been a few weeks, but now the company is starting to run like an actual company. The PM is building out our internal wiki that explains how every aspect of the development process works. He’s running standup. He’s grooming the backlog and monitoring the sprint progress daily. This is what it will take for me to grow the company at this point.

Once things are running smoothly, the PM will start to sift through all our feedback channels so he can start proposing new features. He and I will strategize about what to build and how to build it. Once the meeting is over, he’ll take it to the designer and say we need wireframes. He’ll create the user stories that describe the feature for developers. The developer will build the features and QA will test them while I watch from the back of the room to make sure things are going according to plan. Sprints and releases will start happening regularly instead of just when I can personally muster the energy to get one going.

This means that Hashtag Expert will continuously improve. As long as we listen to customers, the app will only get better and better. And since we finally have a process, adding new developers, testers, and designers into the system becomes exponentially easier.

So now, I’m freed up to continue doing what I do best—tinkering and thinking of new features and apps to build.