12 tips for non-product founders

So, you’re starting a company.

You have a category-defining concept. You know there’s an untapped market for it — customers will be throwing their money at you when they see how it will fulfill their unmet needs.

You’re ready to build. Problem is, you might not have a product background, so you’re unsure how to get started, what to look out for, or how this part of building a business works.

There’s an incredible amount of information out there about product management - from prioritization frameworks (ProductPlan lists 37(!) frameworks here) to Product Requirement Document (PRD) templates to backlog best practices. After leading product and design teams for 4 years at Modsy (on top of the 7 wonderful / hectic years in business development, growth, and product marketing roles at Calm, Foursquare, Rocket Fuel, and Bloom Energy), I wanted to share some of my own product tips and tricks to help you get up to speed just a tad quicker than…time and experience itself will take you.

First, a short list that you might have heard before:

1. Form a healthy obsession with your customers. (Is a healthy obsession even possible?) Get to know them and their pain points inside and out, and validate these experiences continuously. Don’t ever get complacent or think you’ve “finished” solving their problem. Weird thing about the world is it keeps on a-changing.
2. Stay focused on the problem. The solution you come up with might — should, in fact — evolve over time, but the problem is your North Star.
3. Prioritize ruthlessly. Learn how to say “no” effectively by assessing the impact of each request and being transparent as to where that effort fits into the grander scheme of things.
4. Ship a “minimum lovable product” as quickly as possible, and then iterate quickly based on feedback.

And now, some less-preached insights:

5. Understand that developing (aka what our software engineering friends are up to) is almost always going to take longer than you think it should.

This one is hard to grasp in the early days. You’re thinking, “All I’m asking you to do is move this screen from the x part of the flow to the y part of the flow. Why is that so hard?”

It’s so hard because of a million repercussions you may not have thought through yet - how this info is being saved to your backend database, how your event tracking will be affected, if the current code is so fragile that in order to make the change properly your engineer wants to refactor the entire flow, etc. etc. etc.

This isn’t to say development should drag. There needs to be a healthy push/pull and open communication between you as the product lead and your engineering lead, and work to continuously optimize time/effort estimations.

6. Prioritization is one of the most important tasks in product development, and your approach to it should change over time. It seems the interwebs have discussed this topic ad nauseam, so I won’t get too deep into it, but here are my quick thoughts:

When there’s only a handful of people on the team, you might prioritize with a method as simple as brainstorming ideas and giving each person three votes to rank their favorites. As your company evolves, you might move to some form of RICE — which assesses Reach, Impact, Confidence, and Effort — to prioritize. My personal favorite for a company with 20 to 200 people is ICE, or Impact, Confidence, and Effort. Lightweight but still meaningful, and it worked for our team.

7. This one I want to really emphasize. Choose a strong engineering lead to start building. Avoid hiring junior engineers to be responsible for your early tech stack and architecture — the initial cost savings will not be worth the technical debt that is all but guaranteed to accrue.
8. Aim for weekly or bi-weekly “sprints.” This means less talking, more doing. You can brainstorm and hypothesize for months or even years, but you’ll never know how your product will perform in the wild unless you actually set it free. Your aim should be to plan efficiently, knowing that it will take time to fully optimize the product. You’ll ship something new by the end of the sprint cadence, then solicit feedback to guide the next iteration.
9. Website optimization will never move the needle as much as you hope it will. Yes, you want to get your site to a decent starting point, but don’t agonize over it too much in the early days. Unfortunately, “rebranding” rarely has as much of a lift as anyone who pays for it hopes it will.

Do take a look at some well-designed sites (Current and Webflow come to mind) as well as those of your competitors to gain an understanding of common patterns, then incorporate what you like into your own.

In general, basic websites should include:

• a simple navigation bar at the top with

• a single, very obvious call-to-action button in the top right

• a very obvious main tagline/sub-copy/hero image that hooks a visitor and makes them want to learn more
• a simple description about what your company does and the problem(s) it solves
• a benefits section
• a simple pricing and packaging section (do you have a single offering with one price, or have you packaged your solution into three tiers with different features and, accordingly, different prices?)
• external validation such as customer testimonials, external press, etc.
• obvious call-to-action buttons (CTAs) scattered throughout to encourage the action you want your visitors to take

Please note how many times I said “simple” and “obvious.” Simple, simple, simple! Obvious, obvious, obvious! Take a step back and make sure you’re doing your company justice and explaining it in a way that any new visitor, aged 12 to 112, could easily grasp.

As long as you have a decent starting point, I recommend not spending too much time A/B testing your website in the early days. You won’t have the traffic to get meaningful results anyway. Instead, spend that time understanding your users and building them a product they love and will tell all their friends and colleagues about. That’s way more valuable than testing five vs. six onboarding screens in hopes of driving higher conversion. Organic growth is your goal here.

And when you think you’re finally ready to invest a little more in your site, take a look at our portfolio company Prometheus Fuels for inspiration.

10. I realize this may be contentious since there are many companies that make a lot of money selling training courses on product develop cadence methodologies, but at least in the early days, I don’t really think definitively choosing “Scrum” or “Kanban” matters. Just figure out how to prioritize, design, and ship.

As you think about the ‘status’ categories your tickets will move through, consider “backlog (not prioritized),” “not started,” “in design,” “in dev,” “in testing,” “ready for release,” and “done.” What worked for us at Modsy was for the product manager to be an owner of the ticket. As soon as you see it moved to “in testing,” you test when you have time. If there are issues, explain them in the ticket notes and move the status back to “in dev.” Only the product manager or final approver can move the ticket from “in testing” to “ready for release.”

11. Figure out a Quality Assurance (QA) plan that works for your team. Bugs are inevitable, but you want to try to minimize their impact. My former VP of Engineering always preferred that his engineers test their own tickets throughout each environment to encourage a sense of ownership. That being said, we also worked with a small inexpensive offshore team that tested all of our main flows on popular devices/browsers after each release. I know there are many companies automating parts of testing now so take a peek at those too!
12. And last, but certainly not least - create a product roadmap. Get it out of your head and into the cloud! One of the main goals of a product roadmap is to align stakeholders on what you're going to build and in what sequence, and to identify gaps in resourcing that would impact your ability to deliver. This means it can get complicated in terms of how granular to get, and chances are it may end up wildly inaccurate - but starting somewhere means you'll be able to iterate on it and slowly get better at your ability to prioritize and predict effort levels. And always map back to key business metrics as you’re thinking through product roadmap and prioritization.

‍

Kristin (Stannard) Kent is a Principal at Expa and based in Los Angeles. Prior to joining Expa, Kristin amassed over 11 years of operating experience at venture-backed startups, most recently leading product and design teams at 3D home design company Modsy. She has also held growth, product marketing, and business development roles for startups Calm, Foursquare, Bloom Energy, and Rocket Fuel. She has a BS in Civil and Environmental Engineering from Stanford University.

‍