Things I wish I knew when I became a founder: Product Execution
A founder’s guide to creating products people love
Find your why & become obsessed
Find a problem you care about solving and immerse yourself in it.
Before even thinking about product execution, find a problem you care about solving. For me, it’s building products that inspire people living with health conditions (check out my company Invincible here).
While you can certainly build and deliver products that a) you don’t care about or b) don’t have meaningful impact, it sure does make things a lot more tolerable when things get hard.
Everyone has ideas. Few people act on them. Which one are you?
Before you write a line of code, the first step is honing in on the problem to solve — ideally through an iterative product discovery process (see here). The solutions we build should solve real problems — skipping this step will result in a lot of wasted time and effort. You also should take some time to establish some internal/external goals about the product you are building (see: Google OKR process).
This post will give you a deep-dive into the product execution process for software products to help you turn ideas into the real thing.
Bring your idea to life
Make a plan. Then double it. Here’s how you bring your creation to life.
(What to Build) Defining the Product Backlog
Defining your product backlog (aka execution scope) is all about breaking big, unknown things into smaller, executable pieces. This is a key benefit of agile development because it allows you to take unknowns and turn them into knowns — and learn as you go. Product definition should focus on the what vs. the how: don’t worry about the tactical execution details (yet).
Definition always starts with some high-level goals and planning and should eventually get you to a set of scope that your development team can execute against. There are lots of ways to go about product definition, but I’m still a big fan of good ole-fashioned sticky notes (or Figma’s FigJam tool).
Agile development refers to these pieces as “epics” and “stories”. Epics are just high-level groups of functionality, while stories are smaller pieces of the epics that can be built.
- Note: As you start to build out your backlog, you’ll start to have way more scope than you can build (or should). This article won’t get into concept testing, prioritization, or roadmapping, but there are lots of ways to prioritize and consider what to build first.
As you flesh out the product scope, each idea will become its own piece of executable scope. Everyone manages this process a bit differently, but at a minimum you should have well-defined requirements within JIRA tickets that design and development team members can build from.
- Note: Product definition is a team sport. Ideally you’re working with a team of cross-functional stakeholders — including designers and developers — who will all contribute to this plan. Starting first with a high-level plan will make it easier to visualize tradeoffs and ensure you’re still focused on the problem to solve; getting in front of users early and often will keep you focused on the right task at hand.
(How to Build) Establishing Rituals & Structure
As a creative person, I used to think planning and structure killed ideas. After getting a bit wiser (thanks, dad) I’ve learned that the right structure and processes unlock creativity by allowing your team to focus on the most important problems in a time-constrained way.
Work expands to fill the time allotted
- Parkinsons Law
If you’re doing agile development, you should structure your team in 1–2 week “sprints” — or mini-release cycles that put you on the path toward delivering a larger product or release. Personally, I find 2-week sprints to be the ideal (shorter sprints are great for really early-stage ideas or teams that are still learning how to deliver).
Some other key structures or team “rituals” are:
- Release Planning & Estimation: This typically happens at the beginning of a large chunk of work, plus every so often (e.g., monthly) to ensure the team is on the same page and work is estimated.
- Sprint Planning: At the beginning of every sprint, the team gets together to map out the focus for the next 2 weeks. In small teams this is pretty easy; as the development team gets bigger this becomes essential to make sure everyone stays focused.
- Sprint Standups: This is just a quick (ideally daily) check-in from the team on 1) what was done 2) what the plan is and 3) any blockers. it’s also a way to build camaraderie with the team and build momentum.
- Retrospectives: At the end of each sprint cycle, this is a chance for the team to get back together to learn and improve. There are lots of formats for this but ideally you’re discussing 1) what worked well 2) opportunities to improve and 3) action items. For remote teams, FigJam has a bunch of great templates for facilitating this.
(How to Build) Testing & Iterating
As you build, testing and iteration are essential. There are lots of ways to think about this but ideally you’re working closely with your development team to provide feedback and make tradeoffs iteratively. The best development teams I’ve worked with do this as a natural extension of building — the key is not interrupting development time while not getting too far down a path that needs to be undone.
- Note: If you’re building for mobile, TestFlight (for Apple phones) and Google Play Store Beta testing make this really easy. Recorded demos are also nice options to easily get demos into the hands of your stakeholders and users.
Once you start building, plans will change. The key is staying adaptable to what you’re doing while staying focused on the end result.
(Who to Build) Don’t Forget about the Team (!)
Customers do not come first. Employees come first. If you take care of your employees, they will take care of the customers.
— Richard Branson
In the midst of tight deadlines, pressure, and the existential realities of building a company, it’s easy to forget about the team. But it’s essential to building great products (plus…you’ll end up spending more time with your team than your family, so why not have some fun while doing it?).
As a leader, you should constantly talk about the “why” in what you are building. Not only will it make for a better product, it will also help the team be a part of the process and bring value to their work.
Team cohesion is one of the most important factors behind successful products. Find time to gel as a team and your products will naturally get better. You can mix this into normal working meetings — e.g., add a question of the day to daily standup 1x per week — or create your own. Ideally you’re finding time outside of your normal working routines so people can step outside of their bubbles. Being together in-person (happy hours, team, off-sites, etc.) is also a great excuse to do non-working stuff and build trust.
Bring your creation to the world
Launch
It’s time to ship. If you’ve done the hard work, launching should be more about driving awareness and learning than fixing bugs.
Letting your customers know about new features or products is a great way to show you are constantly evolving and getting better.
Measure & Improve
Does anyone actually care about what you built? Talk to users and use analytics to find out. Even when you’ve done early product discovery, incorporated feedback throughout the development cycle, and tested your release, no product survives first contact.
- Tools like Sentry (for bug reporting and analysis), Amplitude (for engagement analytics), and Dovetail (for user research) make this really easy.
Don’t lose sight of your why
Product execution should be about solving user problems, not about shipping stuff. Getting great at execution will help you focus your attention on end user problems and iterating toward a solution that works.
