building a product function from scratch

My latest startup began with just the CEO and myself hacking away on prototypes and product pitches in a classroom at Harvard. We then grew into a small team, building in the back of a newsroom in Kansas. Over the course of a few years, we grew to over 40 full-time employees, and I built out a product team of four.

We live in a lucky era where there are a multitude of resources at our fingertips that can guide teams like ours through periods of high growth and the exciting ambiguity that comes with it. Much of this information, though, falls into three categories:

  • How to build successful products,

  • How to build product teams at established companies,

  • or How to build companies.

I struggled most with tactical questions around building a product function from the ground up at a growing company, and I found that while there are many incredible disparate resources around the web, there is no singular playbook — and I found myself finding most helpful advice living as institutional knowledge from people who had done it before.

My goal ultimately is to create that playbook of best practices and tactical advice for building a product function at startups, pulling from experts and people who have done it over and over. This playbook is a work-in-progress, and if you’re interested in staying up-to-date on it, please reach out below.

In the meantime, I’ve compiled a short list of advice. Here are common threads to consider as you built out a product function at your early stage company:

What is your ideal working relationship with Engineering?

The optimal working relationship between Product and Engineering will vary from company to company. There is no one-size-fits all answer, and that’s the beauty of creating your own engineering and product culture from scratch.

But clearly defining this relationship, and understanding how you can most effectively work together, is mission critical. Your product vision and product specs cannot be built without an effective working relationship with engineers. Engineers will also typically look to the product folks to define this relationship, so it is critical to take charge on defining this from the get-go.

Questions to ask yourself:

  • What will the process be for the handoff of product specs?

  • When will you start looping engineers into a particular new feature? How can you most effectively involve engineers in the initial stages of user research?

  • What quality of deploy previews do you expect?

  • Do you want to see works-in-progress deploy preview reviews, or only the ready-to-release version?

  • Should an engineer go to the CTO/Engineering Manager or to Product if they have questions?

  • What does the Quality Assurance and Engineer feedback loop look like (if Product oversees or owns QA)?

  • How can engineers give the product team feedback?

Check in periodically on these questions, particularly through periods of significant growth and change. You will almost certainly need to adjust your processes over time.

Know your team: What structure and detail do you need for your product specs or product requirement documents?

This could range from a half-page product requirement doc for a complex feature to a multi-page outline hashing out every edge case and technical implementation structure. It’ll likely be somewhere in the middle.

Involve your engineers in this decision. Be nimble and ready to adjust. Know that early on, you may be building hand-in-hand and as quickly as possible with a small team of engineers, and as you grow you may need to formalize your standards.

You should aim to work most efficiently as possible, optimizing for lowest friction to ship a feature. Ask yourself:

  • What is the quickest route for your product and engineering teams to produce error-free, perfect product releases?

If spending a longer time on QA allows you to in turn spend less time on product specs, you might net less time overall when shipping a feature. Or, you might find that spending an extra chunk of time defining every edge case in product specs saves time down the road during QA, and this option is ultimately the lower time-to-ship ratio.

You have to test out what works best for your team, and know that this will shift as your company grows.

How will you measure and use product analytics? What metrics are important to you?

Or, how will you know that you’re building the right new features?

This is something that varies significantly based on the stage of your company. At first, you won’t need advanced metrics to determine if you’re building the right things. The early days version of product metrics might be as straightforward as testing out various prototypes with users and seeing which sticks.1

Then, you might move into the phase where you’re scrappily shipping as quickly as you can, with more critical functionalities to implement than you could possibly have time for. At this stage, your metrics are not found in dashboards. You can’t A/B test a feature if you only have three users to test on. In fact, you’d likely be doing yourself a major disservice if you looked solely at Heap to guide your decisions in this stage.

Eventually, though, you will need product metrics to guide footnote — to inform, not necessarily fully drive — your product decisions. You typically reach this tipping point when you have at least tens of daily active users as well as a set of product features that are all, on the surface, seemingly equal in priority to implement.

You will want to ensure you have the infrastructure in place to learn from these metrics when the time comes. This probably means integrating a product analytics tool much earlier on, and establishing best practices even if you are not using it to guide your decisions right away.

How will you communicate with leadership? Who is the decision maker?

At an early stage startup, oftentimes a CEO, COO, or Founder may take on the role of unofficial product person. If you’re coming in as a Product Manager or Head of Product, you will need to define precisely the role you are playing.

Questions to ask yourself (and others!):

  • Who is the final decision maker on the product vision?

  • Who is the final decision maker on the product roadmap?

  • Who is the final decision maker on product features, prioritization decisions and functionality decisions?

  • What is the optimal working relationship between teams, and how do you best communicate?

Be inquisitive, curious, and humble. Understand precisely what your role and responsibilities are, and understand what is outside of your scope.

How will you solicit internal feedback? How will you solicit internal, but company-wide, ideas?

The product function should be the least siloed function at any company. This also means that while product will be the leaders in determining what to build, and while product will have the data and user research to back those decisions up, there will always be a plethora of insights from folks outside product. Cultivating a culture of ideation and creativity with different perspectives across the company is incredibly important.

Your Customer Success Lead might have a really valuable insight after fielding several phone calls from customers all about the same undiscovered issue, or an Engineer might have a new perspective from the previous industry he worked in that directly translates to a future product opportunity for you.

Ask yourself:

  • What will product’s relationship be with Customer Support? How will product translate feedback received from support tickets, and whose responsibility is that?

  • What will product’s relationship be with Customer Success?

  • How will product build a culture supporting moonshot ideas, and what will we do with them?

  • What creative brainstorming, feedback, or innovation sessions could product host company-wide?

How will you know when it’s time to hire?

You will always have more work to be done than possibly can be done in any given time. So, in that sense, it may always feel like you need to hire. Because of that, much of this decision will be guided by your company’s current resources and growth trajectory.

That said, I recommend basing your resourcing plan on two pillars:

  • Primary: Your product roadmap. You’ve prioritized what needs to be built to unlock particular amounts of revenue that drive your company toward defined company results over a given period of time. What resources do you need to ship those features?

  • Secondary: Tether to team growth. Look at the total number of engineers (2) , sales people, etc. set to be hired. This is a good gut check, but should not be the sole driver in determining product resources.

Then, understand your company’s current time to hire, and work backward from there. This time may be longer than you expect, so think ahead.

Know what you and your current product teams’s strengths are, and hire for teammates that can complement those skills and fill in the gaps.(3)

How does design work at your company and how will it take shape in the future?

Maybe your company has a design-oriented founder who has owned pixel-perfect design across all products since inception. Maybe you’ve relied solely on design contractors. Maybe you’ve had a product designer from day one, or maybe you have no designer at all.

Understand your team’s strengths and weaknesses in this realm, and evaluate honestly what resources you need. Maybe it’s not feasible for the design founder to continue designing every product, or maybe it is in fact feasible for you as Head of Product to keep acting as the product designer for several more months.

No matter where you fall on the spectrum, aim to invest in a strong design framework and culture from the beginning. Use a pre-built component library, and set best practices for Figma, feedback, and design handoff to engineers.

What prioritization framework do you use to guide your Product Roadmap?

At first, you may care most simply about building a functional product. That’s okay, and that will often guide exactly what you need to build next. Then, you may care most about partners or increasing the sheer number of users on your platform. Build for that. A bit later, you may shift gears and need to focus on features that will drive the highest amount of revenue through your platform. Built for that.

All of this may happen within a matter of months. Understand and define your North Star metric, and ensure you’re aligned with other stakeholders on this decision, too.

Then, adjust your product framework to the most effective one given the North Star metric you’ve chosen. Your priorities and resources will change over the course of months and most certainly years. Be flexible in changing the prioritization framework you’re following.

What is your product vision?

This is critical, as it shapes what you’re building toward and why you’re building it.

Tactically, I recommend Marty Cagan’s chapter in Empowered. I turn to this frequently because while “product vision” seems like one of the more straightforward phrases on the surface, I found it to be one of the most enigmatic once I really dug in.

Also, ask yourself:

  • Who defines product vision ultimately? Is it the CEO, the founders, or product?

  • How will you communicate the product vision to the full company?

  • Do you expect your product vision to change? What might signal that you need to rethink your product vision?

  • How will your product vision guide your roadmap?

How will you stay close to your users even as you grow?

I believe this can be one of the more shocking pieces as you transition from being a product person at inception of a company to being a product person at a growing company with more defined structures and teams.

At first, you likely find yourself sitting directly with your users, whether you’re needfinding or hand-holding them through a sticky process or observing their first time using your product. You probably know each user on a first name basis, you probably are watching their every move on Logrocket, and you’re maybe even giving out your personal cell phone as customer support. This is the period where staying in contact with your users just happens.

If you aren’t proactive, you will lose touch with your users as you grow. Ask yourself:

  • What structures can product put in place now to build a culture of user research?

  • How often will product conduct formal user research? What will this look like?

  • Who will be responsible for user research?

  • How will product talk to users not only about our current features, but also future down-the-line problems we may want to solve one day?

  • How will product follow up with users and maintain an effective database of user research insights and problems?

The list goes on and on, and this barely scratches the surface. I’d like to open this up to you: If you’ve built a product team, or if you’re building one now, what advice do you have? What questions do you have?



  1. Have I ever gone on a rant to you about why you should always test out two varying prototypes, not just one asking for feedback? If not, here you go. ↩︎

  2. There is a typical ratio of PMs to Engineers. I tend to find it hovering around 1 PM to every 7 software engineers. ↩︎

  3. Check out the “Four Types of Product Managers” from Elad Gil’s High Growth Handbook as you think about this. ↩︎