During my career, I have managed and helped manage more software products than I can count. Seriously - pretty sure whenever I try to make a list, I always forget something somewhere.
And it’s been a really varied bunch of products. Internal products, external, massively complicated global websites, for a 2-person startup, Fortune 100, Ivy League, and everything in between.
So when someone asked me to explain the difference in products at software startups vs. big, traditional enterprise, it got me thinking. There’s a lot more to it than “big company/small company”. Here’s some insight on the differences - and similarities - in managing all sorts of products.
Resources
Everyone knows that resources at a small, young company are tight. There’s not a ton of money, revenue isn’t always stable yet, and there are only a few handfuls of people across the board. Priceless is the employee who can wear multiple hats and make things happen on a shoestring budget and skeleton crew.
Unrelated to software but still a fun story: my first real job was working for my dad’s company at 13 years old. I earned my keep because I could do data entry, talk to customers and take orders, pick and pack boxes, prepare shipping labels, process returns, help with package designs, and still found time to jump in with general office organizing and whatever random tasks came up.
There seems to be an assumption that folks working in huge companies have all the world’s people and money at their disposal. If only!
The company may have billions of dollars and tens of thousands of people, but those resources are often spread pretty thin. You may be expected to produce enterprise-level results on wholly unrealistic budgets, with tiny teams.
On the other hand, when your product or initiative is considered critical to the company, the resources really are there. So is the pressure, but if you can handle that, you can do some pretty amazing things.
What you do have in a larger environment is more support infrastructure. By that I mean things like, there’s a team of people to help when your laptop has a problem. There’s a dedicated travel agency you can call when your plans get derailed. If you need someone with really detailed knowledge about a particular aspect of your market, or how to do a specific thing, that person exists at your company and will( usually) make time to help you out. That stuff is really nice to have, and I miss it when it’s not there!
Outside help
Large companies have what’s called “preferred vendors”. If you need a design agency, a development shop, a communications firm, or even one-off contractors, you’ll often be told who to engage. Software tools are the same way: you use what the company has decided to use (which is Microsoft).
Sometimes it’s helpful to have some of the research already done for you (and a robust Procurement department is part of that great support infrastructure), and sometimes you want to use a different vendor and have to jump through hoops to make that happen.
Startups are more likely to give you some leeway in selecting the best tools or vendors for the job. That also means you’ll probably be the one doing all the research and vetting.
Process
Product managers are experts on not only their product, but their customers. We drive requirements, features, enhancements, updates, based on what users and customers need. We talk to customers as often as possible, we conduct surveys and polls, collect input from other customer-facing departments, analyze metrics. We also keep up with market trends to understand what our customers might need in the future.
At a smaller company, product managers get to do that. Sure, there are challenges getting in front of customers, and you may have to incentivize them for their time. But you can make it happen.
At a Fortune 500? Well, you can probably get in front of your customers if you’re managing an internal product. Because then your customers are other employees.
But when a traditional company has an external-facing product, whether it’s a website or an app or a store finder or a training signup, you don’t always get much information at all. My experience is primarily in the B2B space, where big contracts are closely guarded by territorial sales reps who don’t want you talking to “their” customers. And in pharma, where talking to patients comes with major privacy concerns.
Marketing teams do thorough research, but may refuse to dig into questions that might give you the insights that you need. And they don’t always even provide access to the research they do have!
Politics gets in the way of proper customer research a LOT.
There are a lot more voices dictating what to do and how to do it - and those voices are less likely to be customers or users.
Pace
I’ve seen a fast pace at both startups and large enterprise. The difference is in their effectiveness. Large enterprise keeps its employees working against tight timelines. But those timelines are often pretty arbitrary (“launch before Dec. 31 because that’s when our accounting resets”, or my personal favorite, “you have to set a date so just pick any date”). Or the deadline changes, often on the whim of an executive. So there is a lot of “hurry up and wait”, and the rushing doesn’t drive faster actual results.
There is also the immensely maddening budget process, in which you can't get money for a big project until it's approved during a certain time of year, and the money (if approved) won't be available until the following year. That is not a good match for any kind of modern software development.
Because there are so many initiatives happening at any given time at a large organization, there is also more project management overhead. Each product needs to interact with others, owned by other teams, with different roadmaps. So some of that fast pace is going into coordination work, instead of directly benefiting the product.
One time, I was tasked with building a product that would be shown at a convention. So the deadline was actually not at all arbitrary - launch before the convention. However, when the request came in, there were seven weeks to build the thing, from requirements to full launch. At a 100-year-old traditional B2B company that moved at the pace of a 100-year-old traditional B2B company. During the summer, when the key stakeholder would be absent for four weeks out of the seven, but also needed to approve every aspect of design and functionality.
Poor planning by senior leadership, and a strictly hierarchical work structure, created a serious time crunch and a couple all-nighters. (Did I build a functioning product in those seven weeks? Yes I did. Am I proud of that product? Nope.)
Smaller companies tend to move fast because they have to. You need to drive revenue and customer acquisition in order for the company to survive and grow. You need to show results to keep investors excited.
A smaller team means more focus. Goals and deadlines that change less often, and usually change with good reason. A fast pace to get to something good, as opposed to a fast pace only to start all over again, or have your initiative cancelled.
That’s not to say that every startup is super efficient. I have definitely seen startups that rush rush rush toward a semi-arbitrary deadline and never quite launch. In those cases, the problem is usually that they haven’t defined their product well, what “done” actually looks like. This is especially common in the pre-seed or seed stages, when they’re still working on an MVP and the founders haven’t quite found their footing yet.
Philosophy
This is where I see the biggest difference between the software product that a software startup sells, and a software product at a large, traditional corporation.
At a small, young startup, the product pretty much IS the business. You sell one thing, maybe with tiered access or additional services offered, but everything based around the one product. So that one product is vital to the success of the company. It may be a small pond, but every fish is huge.
The company will therefore put a majority of its resources into researching, designing, building, and supporting the product. The product and engineering teams sit at or near the top of the organization, with major voices and empowerment.
At a Fortune 500? There may be hundreds or even thousands of products.
Most of them are internal, supporting various business functions. These days, many or most of them are third party, but there are still a lot of custom, in-house products.
With few exceptions, these products enable specific business processes that may help one or two teams. They are very small fish in a massive ocean. They get more limited resources, they’re often managed by someone in IT who doesn’t have a seat at the proverbial decision-making table. Plus, when the company does a push to reduce custom apps, these small support products are the first on the chopping block.
Traditional companies do offer external-facing software products. Keep in mind that those external products are usually some form of sales enablement or marketing, and are still not the core product or service offered by the company. So product management for those can be a mixed bag.
I worked for one company that put significant resources into its (massive, global, compliance-enabling) website, which additionally housed a number of apps for various audiences. They maintained tight ownership and control, which enabled a smooth customer experience, and spent significant money on technical leadership as well. Managing this portfolio was a pleasure.
Another company took those infamous corporate siloes to the extreme. Every part of the website and every customer-facing tool was owned by a different department, designed by a different agency, developed by a different vendor. The result: whichever department had extra budget sitting around got to do what they wanted, even if the rest of the experience suffered.
One thing I will note is that traditional companies, and especially traditional B2B companies, aren’t always as advanced as their smaller, younger cousins when it comes to software management. Product managers in those organizations often don’t hold product manager titles, even as they’re doing the work. And they may find themselves having to be evangelists for modern product management itself, convincing executives that it’s necessary and deserves resources.
Bottom line
Organizations both large and small, huge and tiny, handle product in their own ways. With pros and cons to each. I have found it uniquely valuable to have experience working with all sorts of different organizations in several industries. Each has taught me something I was able to bring to other jobs and clients.
And while there are definitely many differences in products and how they’re managed at different types of companies, there are more similarities. As there should be.