
Startups: When to Hire a Product Manager
We Don't Need No Stinking Product Management!

The Birth of Software Product Managers
I started out my software career as a subject matter expert (technically a “Business Analyst”) at the turn of the century – 1999 to be specific, with Y2K looming over our heads. But I didn’t need to care about Y2K, right? I was an SME. Issues regarding 2-digit years and the new millennium were not our concern – that was engineering’s problem.
I was working at a "startup" that was about 8 years old when I got there. It wasn’t technically a dot-com. It was a fat client/server application. I don’t remember if it was PowerBuilder or Java Swing, but it was something of that ilk. As I mentioned - this was in 1999. This fact alone would date myself with other old AF people like me, but if you were born after the 1900's you might be thinking, "WTF is PowerBuilder 🤔?" The answer to that is: you don't need to know unless you really really want to get a job maintaining sexy legacy banking and manufacturing systems. Really, even if you do, leave some tech jobs for us olds who hate change and want to bathe ourselves in old technology and reminisce about the days before the interwebz when "user experience" wasn't a thing (or rather, it ranged from tolerable to atrocious) and you had to install shit on your Windows 98 computer and update it over and over again in order to use it - almost as many times as you had to update Windows 98 - and you couldn't work from home because your computer and all the applications thereon were at work.
(As a side note, the fact that PowerBuilder still exists and is being maintained and updated today would seem to indicate that anything that moves "at the speed of business" isn't really moving all that quickly.)
Look at this beautiful PowerBuilder app! I almost forgot how it opened up separate windows in random places for everything, which was super convenient for finding the thing that opened up the last thing before you closed the other thing. It's in black and white because it's so old, it was created before color pictures 😏. Hey! Remember Netscape? (If you don't understand why I ask, you probably don't.)

Fun fact: I was a product manager at AOL for like half a second. I managed webmail. One of my tasks was to integrate Netscape mail and AOL webmail, but I wasn't there long enough to complete said task (or any task really). I was also tasked with figuring out how to provide a seamless user experience when switching between AOL webmail and AOL desktop mail, because... wait for it... they didn't share the same database. I mean, why would they? I was silly for asking. That's just crazy talk. When I asked an engineering VP when they decided to build something on the client versus the server, he shrugged and said, "we do stuff based on whichever team has the most bandwidth." Oh. Ok. That makes... um.... NO SENSE WHATSOEVER. Anyway, that's why I got the hell outta dodge faster than you can say, "Keee-errrrr-beeee-eep-ong-dee-ong-waaahhh-urrrrrr. You've got mail! 📬"
OK, so, back to my first product management job... when I was hired there was a push to re-platform all our products as web applications. If you recall they were initially client-server applications, but with the advent of the interwebz we were doing something crazy called "modernizing". This was before SaaS was a thing, so you still needed to install the software on a server hosted by you, so it was web-based, but you could only access it via your internal network. This gave you the added convenience of being able to access the application from any computer attached to your network (rather than having to install something on everyone's computer). As a bonus, this also let you secure the application and its data within your network, rather than exposing it to the evils of the whole world, but eventually that bonus was forfeited in the name of convenience, which is par for the course. In today's world convenience always trumps security, much to the detriment of society at large.
Sorry, I digressed again.. my first company built global trade compliance software - essentially software that helps you file the right paperwork with a country’s customs agency to properly import or export your goods into/out of a country - though there are a lot of complex rules depending on what you are importing or exporting, in addition to rules from other agencies like Food & Drug and Agriculture and Defense. Also, duty rates (also known as tariffs) are actually very carefully assessed based on what each country produces and what each country doesn't produce but needs. Assessing a random flat tax against random countries is, in two words, pure dumbassery. I'm just throwing this in here to illustrate the complexity of trade rules and not for any other reason that may or may not be relevant to current events.
So I was hired because the current SME was having a really hard time translating government regulatory requirements into something an engineer (with no domain expertise) could code off of. When I interviewed for the position, I happened to be an expert on US Customs import rules and regulations with no experience in software, BUT I had a technical degree.
The hiring manager was excited that I had taken programming languages in school. I told her that it was Pascal and Fortran, so I’m not sure how valuable that was. (This was before I learned to... embellish my qualifications to appear as qualified as possible, though this was also when tech companies were throwing money at people with marginal experience... You have a degree in bagpiping and puppetry? YOU'RE HIRED! ⬅ This isn't really much of an exaggeration. I had a friend with an art history degree and she got hired at a tech company and had absolutely no idea what she was doing and they didn't seem to care.)
Anyway, the hiring manager said, “I don’t care. If you know how to program, you know how to be logical and if you can be logical, you have the skills to translate business into tech.”
And lo and behold, she was right…
When I started there was no such thing as a product manager. I mean there was at companies like Microsoft, but at startups, the concept of such a role hadn’t really caught on. However, not long after I started when people figured out that I actually could translate business requirements into something engineers could code off of (I could even spoon-feed them pseudocode), the Product Manager role was born and I was the first one (I mean... not like the first one ever, but the first one at that company).
Bridging the Gap Between Business & Technology
It took 8 years for that company to realize they needed someone to bridge the gap between business and technology. The product I was hired to work on was brand new with no customers and in terrible shape. It was virtually unusable. During my first week there I attended product training for the product I was taking over, and I had no idea what was going on within the application and I UNDERSTOOD the regulations and the processes - or at least I understood what the processes should have been. Even the instructor got confused and lost. Several times.
The company already had an established product to help with export regulations, but export regulations are infinitely less complex and easier for laypeople to understand than import regulations (my inherited product's wheelhouse). There is no doubt in my mind that, had I not been hired, that product would have failed. I know this sounds super braggy and I don’t mean that it had to be me specifically, but they needed someone different than the non-technical SME that I replaced. (Stay tuned for a follow-up post on my unpopular opinion that the most effective product managers need to have a technical background.)
This was also during the dot.com boom when anyone and everyone was building a cool consumer web app and getting scads of investor capital with ridiculous valuations, even with half-baked monetization plans. On the other hand, most business applications had been built to automate historically manual processes, and everything was based on what customers (or potential customers) asked for. Very little time was invested in effectively predicting future customer needs and building them proactively, perhaps because nobody was all that good at this yet (remember Clippy?). The advent of SaaS ushered in the need for a B2B product manager to be more strategic, rather than just a glorified project manager. Effective product management now required equal parts strategy and strategy execution.
Incidentally, my first product still exists today, 25 years later. It was bought and sold several times over and (hopefully) re-platformed a few times, but it is still a viable product (this bit is intentionally super braggy).
Most Early Stage Startups Don’t Have Product Managers
Fast forward 20+ years and most startups still don’t hire their first product manager until several years in. 2-3 years seems to be around average - either that, or around the time the company has hired between 1 and 2 dozen engineers.
In cases where the founders are engineers, generally one of the founders can effectively act as the product manager (though not all engineers are good at this, which seems to contradict my statement above that product managers should have a technical background, but it does not and you're just going to have to hold your horses until I have time to write that post before you flame me). Also, in cases where the product is something familiar or tangible (most B2C products), it’s easy to get by without product management for a while if the engineering team is small enough.
What some companies fail to recognize is that product management isn't just about building roadmaps or executing on them. You need the visionary to set the vision first, and then you need someone to take that vision and execute on it. In a startup one of the founders may be the visionary, but if they can't take that vision and execute on it, then they need someone else to take on that role. You can't just throw a vision at engineering and expect them to produce anything close to that vision.
You Don’t Know What You Don’t Know
Many (not all) startups are created by engineers with a great idea, but they often know nothing of ideal customer profiles, market or market fit, product vision, etc. This is fine and perhaps even good. Too much structure and planning can squelch innovation and if they can manage to get an MVP out the door without outside investment, they won't have VCs breathing down their neck telling them what and what not to do (which can also squelch innovation, but in time having some guidance is a good thing).
Because product management tends to be an afterthought, startups often don’t start thinking about the skill until they start floundering. Maybe they can’t figure out who their ideal customer is. Maybe they know their ideal customer, but they aren’t gaining traction because they aren’t prioritizing the right features. Maybe they aren’t getting anything done because startups with no product oversight often like to squirrel to the next bright shiny object only to be distracted by another bright shiny object.
I’ve been hired as the first product person in most organizations I’ve worked and the one thing that everyone has told me is, “I wish I would have hired you sooner.”
There is this sweet spot within a startup, usually sometime after MVP and sometime before the company starts floundering (at some point, without product oversight, the company will start floundering, even if otherwise successful), is where they should start looking for a product manager. (Technically, the first product person should be a founding member of the company or one of the very first hires, but I realize that this isn't always feasible, so at/around MVP can be early enough in most cases.)
The first product person should be a combination of strategic and tactical. They should have several years of experience. Often companies will try to train an intern, or move an engineer, or hire a project manager to fill that gap, but you need an experienced product manager who’s willing to roll up their sleeves and work alongside the engineers day-to-day, as well as talk with stakeholders and customers, while putting in place a process for their role. They also need to be able to work with the visionary to create and evolve a vision and a strategy that drives the roadmap. They cannot be someone who just builds roadmaps and defines OKRs and throws them over the wall at engineering. They also cannot be someone who just works alongside engineering to execute on a roadmap created by someone else (a project manager's sweet spot). They need to be able to set and evolve strategy and vision, build a roadmap towards that vision, and then execute on that roadmap with engineering.
It's actually a very rare person who can excel at both strategy and execution equally, and a single person doesn't necessarily need to be wholly responsible for both, but someone in the company needs to be able to compensate for any talent gaps, so when you start to think about hiring your first product manager, you need to figure out what skillsets are most important for this person to have, based on the makeup of your current team.