Switching from consulting at the start of my career into product management was the best thing that's ever happened to me professionally. Nothing against consulting (it's a mostly honest living), but making things just motivates me more. What you realize quickly when you make that switch from professional services into product though is that products are incredibly unforgiving. If you're stuck the night before you owe your client a deliverable, you can almost always scrape something together and make a decent showing. There's no dancing around broken software though. If the lights don't turn on when you flip the switch, that's it.
Or at least that's what I thought for a long time. The reality is a little more nuanced.
Delivering software over the web has greatly reduced the finality of shipping a piece of software. Now that updates to the code can be pushed every few weeks, or even continuously, then you re. Now that SaaS companies mostly embrace some form of agile development and push new features on a rolling basis, products are more fluid than ever before. The benefits of this are many, but the flexibility that SaaS and agile can lead teams astray too.
As a product manager or executive in charge, there's something you should always keep in mind in a world where the state of a product can change so rapidly:
Every company has the product it deserves.
Agile and SaaS offers non-stop opportunities for short-term gratification. We've all seen it or done it. We keep tech debt around to fast-track a feature; we spend a sprint or two to make sales demo "pop" instead of advancing the core product; we implement a quick and dirty feature to get it in customers' hands faster; we decide to iterate and "fail fast" instead of doing real research to pinpoint market needs. There's always next sprint; the sun will come up tomorrow.
A piece of software reflects the cumulative decisions of the executives and product team over time. Their priorities dictate what to build, what not to build, and the overall level of complete-ness. Great products and bad products both reflect the management teams who are responsible for them. If your product just isn't where it needs to be, remember:
It's not the architects.
It's not the developers.
It's not the designers.
It's the management team. And the product team. And if you're calling the shots, it's you. There's a quote from the book Peopleware that I refer to often that captures as well as any how software problems stem from management failures more so than technical ones:
Perhaps the answer is what we’ve come to think of as the High-Tech Illusion: the widely held conviction among people who deal with any new aspect of technology that they are in an intrinsically high-tech business…Just between us, they usually aren’t. The researchers who made fundamental breakthroughs in those areas are in a high-tech business. The rest of us are just applying their work. We use computers and other new technology to develop our products or organize our affairs. Because we go about this work in teams and projects and other tightly knit working groups, we are mostly in the human communication business. Our successes stem from good interactions by all participants…our failures stem from poor human interactions. (emphasis mine)
If you're interested in getting to product-market fit for your SaaS product or better understand your target users and buyers, we want to have you on UserMuse.