Why you need to build a product discipline within your startup - before you hire a product manager
In the early days, founders set the product vision and work with development teams to make their idea come to life, making daily decisions on what to build.
Once things start to click and customers start signing up in droves, the work of building software really begins.
Users who love your product request all sorts of additions.
“If only it had feature x”.
You’ll happily tell them “Great idea! We’ll add it to the roadmap.”
Over time, this roadmap just becomes an endless list with a million ideas, and none will ever see the light of day.
Even if you had an infinite amount of engineering time, all of those features would make for a bloated product that nobody wants to use.
Since founders are unwittingly the first product managers at their company, these types of decisions fall on them. What do we build, and in what order? More importantly, what do we say no to?
When I talk to founders who are playing this role, they usually don’t know what product management is or how the role of “Product” differs from software engineering.
Some even have a developer or project manager play the role of the product owner within an agile scrum team. But that’s not the same as a product department.
OK, so what is Product?
The role of Product is to focus precious engineering time on solving the most valuable customer problems in a way that grows the business.
Another way I like to say it is that product maximizes the return on investment of the engineering team.
Any software business has a lot of stakeholders.
Customers want bugs fixed and new features added
Customer service wants bugs fixed or improvements so they can make customers happy
Prospects need certain features to adopt
Marketing and sales want those features added so they can sell more
CEOs, managers, and boards are responsible for the ultimate success or failure of the business
Engineers want to build better tooling and infrastructure and refactor their code to be more elegant and easy to maintain
Managing all of these stakeholders is hard because everyone has their idea of what the product needs, but you can’t satisfy them all.
Building a great product is hard.
Doing it with all of these voices at the table pushing their agenda is even harder.
A product discipline is about creating a systemized way of deciding what gets built and when.
It involves:
working with all of the stakeholders to get feedback, and buy-in.
helping the dev team build improvements,
helping the marketing team promote those improvements, and
helping customer success assist customers with onboarding and troubleshooting issues that inevitably will come up.
I’ve already outlined how a product owner within an agile team isn’t necessarily the same as a product manager. If a startup is too early to hire a dedicated PM, then the founder should wear this hat.
If you can build a great product discipline early in the company, then when you eventually hire a product manager they’ll be more successful because the foundation will be laid.
So what do you need to know?
Product focuses on valuable customer problems.
There’s only one way to really know customers’ problems: Talk to them. How often do you get on Zoom with your customers?
Ideally, it should be at least once a week.
In the early years of running Proposify, I automatically sent out an email to every customer who signed up for a free trial. I thanked them and sent a Calendly link to book a 30-minute chat with me.
Eventually, there were too many trials and not enough hours to talk to them all, so instead, I only sent the email out after they signed up for a paid plan.
Eventually, there were too many of those people so I’d segment it by plan size or only send it out to every few new customers.
There is no replacement for this activity, especially early on. You need to take the pulse regularly.
Asking why people signed up helps you understand the job they’re hiring your software to do. This gives you insight you can feed back into your marketing messaging.
In the early days, customers would tell me they want to streamline their proposal process. They kept using the word, “streamline”. So I made the headline on our home page say “Streamline your proposals” and it attracted a lot more users.
Marketing hack: Use your customer’s words in your messaging and you’ll attract more of them.
Often when a customer books a call with you it’s because they want to learn more about how to use a feature or they want to tell you about something that’s broken in the software. It can turn into a support call, and that’s totally ok, especially in the early days.
If you as the founder are helping them use the product this creates a bond with the customer and forms a connection to the brand that can last many years.
As your company grows they’ll tell you “I was one of your first customers and I remember you getting on the phone with me at midnight to help me troubleshoot.”
When the customer asks for features, this is your chance to understand the ‘why’ behind the ask. As you deeply understand problems they want to be solved, you’ll be able to bring it to your team and get back smarter solutions.
Having these calls regularly, you’ve already begun to build a product discipline.
When you decide to tackle a feature and give it to engineers, you’ll have done your research and won’t be guessing at it.
The biggest risk in software development is building a feature nobody wants, or they can’t use. Engineering time is expensive, both in hard costs and in opportunity costs. If you waste enough engineering resources over time, your product stagnates.
The act of product management is derisking the work ahead of building it to ensure four key risks are mitigated:
The customer - will anyone use it? Will they pay for it?
The design - can people figure out how to use it?
The technology - can we actually build this? Is it feasible?
The business - will this improve our business? Will it introduce legal or financial risk?