readme: Here’s a mock interview between myself and a simulated ceo of an early-stage startup. all questions are prompted by chatgpt 4. all responses are unassisted and unedited by ai. you can read the full conversation here.
jump to: problem solving, complexity, prioritization, decision making, engagement, data, culture.
Q1
CEO: Thank you for joining us today. Can you start by telling me about your approach to problem-solving, especially in the context of a startup environment?
Me: Sure thing. The most important and hardest thing to do consistently is make sure you’re working on the right problems and the right metrics to begin with. The second most important thing is to be honest — did you actually solve something meaningful?
Startups have no shortage of problems to work on coupled with heavily constrained resources and external pressures. It’s easy to get lost. It’s also OK to ignore even big problems.
For early-stage companies, product-market fit is all that matters and should be seen as the primary problem to solve. Everything else is secondary or in most cases irrelevant.
Finding product-market fit is, however, elusive. Most companies never figure it out, but what’s worse is pretending you have it and doubling down on an illusion. It’s convenient to celebrate shiny metrics, but eventually the music is going to stop.
So how do you find product-market fit? There isn’t an exact formula. It takes actual hard work and humility which can be scary.
It then helps to simplify.
Set a goal to get people using this thing consistently. Ignore everything else.
Choose action.
Employ tactics to accelerate true learning. Operative word there being true.
Be brutally honest about results to hopefully move down the right path.
Learn. Adapt. Overcome. Repeat.
Q2
CEO: Thank you for sharing your approach. It’s clear that you value focusing on the right problems, being honest about results, and maintaining a laser-focus on finding product-market fit. Now, let’s move on to the next question:
Can you give me an example of a complex problem you’ve faced in your previous roles and how you went about solving it?
ME: Much of my experience has been in Construction technology. Everything about construction is messy and complex.
Take estimating. How much is this thing going to cost. It’s a simple question but requires multi-dimensional modeling and fortune telling if you want to be in the ballpark of right. Materials and labor are dynamic and hyper-local. Indirect costs, contingency, dimensions of risk…these things aren’t straightforward. It’s why you see any serious construction company armed with a 10GB excel file and why you also see estimates done on napkins. This is a curious observation to kickstart the discovery process. Maybe we don’t need to solve the hairy version of estimating first. Or at all.
So we dug deeper.
Why do companies take such different approaches to estimating?
What kind of estimates can be imprecise? Where or when is this ok?
What is the actual purpose of an estimate in the first place?
After conducting quite a bit of customer research, we learned something interesting — residential general contractors perform multiple estimates. The first one though, does not need to be precise — it needs to be fast and easy to do.
Now we have a more approachable job to be done for a v1: ‘As a GC, I need to be able to produce a decent estimate on the same day I meet with a new prospect.’
Progress. But what is a decent estimate?
Here are the broad strokes:
- +/- 20% on price
- Level of detail should show at least the main trades itemized
Very simple. So why is it hard to create this quickly?
Mobility for one. Excel is clunky if you’re off the desktop.
Second is lack of access to even mediocre cost data.
Those two truths set the stage for a v1.
- Create a simple UI that was excel-like, but didn’t require clicking, formatting, or formulas.
- Approximate real-time material and labor costs with a good model. This was the innovation.
It still wasn’t easy, but scrappiness can pay off.
Since we were only concerned with residential, building types are straightforward. Single-story home, two-story home, home with basement. 3 main flavors that can be mapped to a scalar.
Location is the hardest to model. Labor and materials can have wild swings between geographically close places. But there are good proxies. Like all the readily available information on things like Zillow. The selling price per SF is a good foundation. Nashville costs 20% more than Little Rock. It also helps define a dynamic baseline. This data is piping in regularly.
It’s still not +/- 20% so we needed to tune it further. There are construction cost books that have these ‘adjusters’ by location. Labor in Sacramento is 13% higher than the national average. Stuff like that.
That’s the general concept. You have these datasets running in the background and the user has to supply just three things:
- Location
- Project Type: Single-Story, 2-story, and with or without a basement.
- Size
And a decent estimate is spit out.
Now, before we get too excited, one important note here is that just because this was an easier problem to solve first, with a validated need, it doesn’t necessarily mean it’s good for us or the larger market long-term. Before overcommitting, it’s important to think several steps ahead on how the bet could play out and what it could lead to. Sometimes it’s hard to come back and reverse course.
Q3
CEO: As the first product manager in our startup, you’ll be responsible for setting priorities. How do you decide what to prioritize when resources are limited, and there are multiple important tasks to tackle?
ME: As an early PM, we need to think about not just ‘product’ priorities — what do we build next — but global priorities for the organization. In either case, first step is to make sure you’re working on the right problem.
The right problem should be connected to either building a great product or validating a great market. Depending on the maturity level of the business, you’ll over-index on one of these dimensions.
A good starting question is ‘what’s your metric?’. The single most important metric that is a proxy for your mission, business, and most importantly customer value. A durable KPI.
Continuing with the estimating example, let’s say that metric is ‘estimates sent each week’. If this goes up, customers are reaching a key value moment, and if this goes up, it probably means the user base is growing.
Priorities fall out of this.
- First, are we able to measure this metric? If not, quickly prioritize some base level of instrumentation.
- Map out the critical path. What’s the user journey and where is it getting gummed up? Maybe it’s still incomplete. These all become levers to prioritize sprint over sprint.
Always easier said than done. This type of prioritization is what I would call more ‘block and tackle’. If you have a clear target market, user, and metric, the name of the game is simply focus.
It’s rarely that clear early on. Prioritization would be much different if we articulate that KPI slightly different.
- ‘Estimates sent each week by residential contractors’ vs. ‘Estimates sent each week by new users’ vs. ‘Estimates sent each week by commercial contractors’.
Evolving market strategy has a huge effect on how we prioritize. As a PM — or whatever role you morph into — you need to challenge the organization to reach shared understanding and clarity when it comes to strategy.
Do this regularly.
Drive accountability in other departments particularly around metrics to get organizational and strategic priorities solid. It’s easy for both emotion and inertia to pull the product in a less than ideal direction. Bad markets can appear good, and it’s convenient to assume good will be great, we just keep going.
In these situations, you can prioritize feature work incredibly well, but it doesn’t really matter if you’re working on the wrong problem. Eventually growth will stall out, it becomes very painful to rebuild or pivot, and you’ve become a great small business, not a startup.
In the words of Andreessen, market matters most.
Q4
CEO: Can you tell me about a time when you had to make a tough decision about what to build next, and how did you navigate that decision-making process?
ME: You need a system for decision making. More specifically, you need an objective system to point to that allows you to say no.
Here’s a real and very common example of competing priorities:
- Your CEO wants you to focus on this intricate problem in a niche user group.
- The Sales team is banging the table for a new CRM integration.
- Customer Success thinks the highest priority is fixing an import feature to help new users get setup. Oh, and by the way, this customer will churn if we can’t handle multiple PDFs better.
- The dev team has committed half their resources to fixing tech debt and wants to start working on multi-platform versions of the product.
- And your recent customer feedback has called for more advanced accounting features.
It’s chaos.
You need to filter out all the noise. Everything that can wait. Everything that doesn’t directly move your one or two true metrics that matter.
The first place to look is your OKRs. If you have them. Or anything similar to a quarterly/yearly goal as an organization or at the Product functional level. What’s one of your current metrics or goals as an organization?
Q5
CEO: Our current primary metric is user engagement, specifically the number of daily active users on our platform. We believe that increasing this metric is crucial for our growth at this stage. How would you use this information to prioritize the competing priorities you mentioned earlier?
ME: DAUs can be influenced in really two ways — get more users or retain more users. Getting more users is much easier, but not as meaningful. It can become a vanity metric if not defined with intention. If we want to just monitor DAUs, it should be based on completing a valuable action, not just any action. Something in the critical path of value capture.
I would advise to monitor a metric like DAU/MAU to keep an eye on general retention alongside just total DAUs. Just a side note.
So, if boosting DAUs was the main objective, we could define a decision-making system around a few pieces of logic:
- Growth: How efficiently would this expand our potential market?
- Growth: Does this idea improve trial signup conversions or onboarding?
- Retention: Does it shorten time to value? (e.g. export events)
- Retention: Does it enhance the ‘special sauce’? (Make what we’re best at even better. Core differentiation)
If it’s just the DAU number we want to move, we would overweight growth.
Now we can take any new idea and rate it for each dimension. I would also add some guess at level-of-effort as part of the prioritization formula.
Let’s take the CRM integration.
- It’s not very hard, so LOE would be maybe a Medium.
- Market Expansion: probably a 1 or 2
- Signup efficiency: Maybe a 1. Maybe even 0.
- Shorten time to value. Probably decent here, let’s say 3.
- Enhancing special sauce. Doubtful. Pretty low, maybe a 1.
Add them all up and factor up or down based on LOE, and you have a ranked list of ideas.
Far from perfect, but directionally correct and simple. Everyone can understand it.
Looking at my example earlier, the end result is all of the ideas are pretty weak in terms of how well they leverage a top-level success metric, so the answer was ‘none of the above’. However, the optics aren’t great when you say to everyone, “thanks for all the input, but we’re just going to do what I want to do”. That doesn’t exactly fly.
That’s why you need the system. You can design the framework as an organization. Pretty much just an articulation of OKRs and or goals/metrics. Then you have something to point to when emotions start to run.
“We agreed these two things were most important, and these were the biggest levers to push on. That’s why X idea needs to wait and why we chose to prioritize Y”.
Making tough decisions is the job. That’s really what it comes down to every day. If it seems obvious or simple to decide what to build next, you may need to challenge yourselves further.
Communicating these decisions and getting everyone on the bus is the tricky part. Clarity and consistency in logic is therefore critical, not just for you as a PM, but as an organization.
Q6
CEO: Can you share your experience with data-driven decision-making? How do you use data to inform your product decisions?
ME: This topic is vast, so I’ll aim for brevity.
I rely on data to guide every product decision. Whether setting quarterly goals or conducting A/B tests, both qualitative and quantitative data play crucial roles in the planning process.
We use data to either validate hypotheses or generate new ones. The former approach is more deliberate, while the latter is more organic and exploratory.
In essence, data enables us to be both scientific and creative. It’s fundamental to doing the work.
In my previous role, I started each day by reviewing dashboards, examining key product metrics, customer service metrics, product-led KPIs, and the current quarter’s OKRs, among others.
I would also maintain a running list of curious thoughts, ideas, and questions. Each day I would pull an idea, go down the analytics rabbit hole, and see if something interesting would be discovered. Whatever I learned that day, I would document and share with the wider org.
This ritual was about forming connections, clarifying thoughts, and sparking innovation. It also facilitated communication and alignment, softer aspects of the job that are essential for effectiveness.
Building positions and strategy on good data insights significantly reduces organizational and planning overhead. Numbers are universal and cut through the noise.
We’ve all been in meetings where you lose hours arguing about what is true. Data allows you as a team to argue about why something is true and how to change it.
I’ll pause here. Let me know if it would be helpful to discuss a specific example, such as using data to craft OKRs or conduct experiments? Happy to go into more detail.
Q7
CEO: Finally, as the first product manager, you’ll be setting the tone for our product culture. What values or principles do you think are important to instill in a product team, especially in an early-stage startup?
ME: Let me walk through some of the beliefs that come to mind that I have come back to time and time again. These have helped me find consistent success in very different organizations and are battle-tested.
Perfect is the enemy of good. Be ok with ok. Nothing is permanent. Value creation is a function of learning velocity which is a function of execution velocity. Get things out the door. Find shortcuts, fake it, do whatever it takes to get something into the hands of your user base.
Be a cool passenger. Startups are like a hang glider. You jump off a cliff together and while you have control over your actions, you can’t control the wind. There will be bumps, turbulence, some people may get dizzy and vomit. What you don’t want to be is the passenger that is screaming and yelling at every turn. Everything is going to be fine. Be cool. Don’t add stress to the situation and enjoy the ride.
Get Big on Metrics. Live, breathe, share, celebrate, and fight over metrics. Have your own metric. Hard code metrics into every product process that we have. Hold other functions to the same standard. Clarity and shared truth will lead to great outcomes and individual purpose. Metrics will set us free.
Live in the Future. Embody the user but think beyond their immediate problems. Let some fires burn. Dig for true insights and cast a bold vision. We’re here to make waves not ride waves.
Strong Convictions Loosely Held. Be passionate and hold strong opinions. Be bold. Be willing to adapt and change your mind as you mature. It’s something to celebrate. There’s no ego or shame here.
Communication is our Superpower. First, we listen. We gather holistic intel from colleagues, the market, and our users. We are obsessive over written communication. Clear writing comes from clear logic, and clear logic gets everyone on the bus. Our default mode is to over-communicate. Everyone knows what we’re working on and why. We prioritize discussions with our key customers and build direct lines of candid feedback. We speak honestly with each other.
Trust the Gap. Assume there’s a good reason for a lapse in performance or a moment of unprofessionalism. We all have bad days. Life comes at you fast.
Following my own advice here, this belief system isn’t cast in stone and should be seen as a draft. It’s a starting point to set the tone, to augment the company culture, to work in harmony with the mission, and ultimately be refined by the individual personalities and styles on the team.
Leave a Reply