What Exactly Is Your Product?

18 February 2025

Editorial note: This post is from the early days of HappyHQ. Some of the ideas and details have since evolved, but these initial thoughts shaped how we think, so we're preserving and sharing them as written.

Here's a question that seems simple on the surface: What exactly is your product?

If you're like a lot of SaaS startups, you probably think about your product as the application you're building. The thing your customers log into. The thing that solves a problem worth building a company around. We've been there before. It's an easy choice to make. But here's the catch: the product is more than the application you're building. We learned this lesson the hard way, and it has us thinking about things differently as we build HappyHQ.

You're building your first version. What an exciting time! Everyone is heads down trying to breathe life into this idea. It feels a little bit like a race. The faster you get your product out the door, the sooner you'll have customers. The sooner you have customers, the sooner you can do....everything! At least that's how it feels, right? Sure we need a marketing site, but we'll get something basic out the door quickly so we can get back to building our actual product. We can figure out those other things once we have a product customers can use.

Then it happens. Your first real customer is in the pipeline. Everyone becomes focused on closing the deal. On the next call, there is a casual ask for documentation. Everyone panics. We don't have any docs. We can't lose this customer because of...docs. So you do what we've seen countless times - whip up some quick docs just for this customer. It's the fastest option and you know you can provide them exactly what they need. Problem solved! This customer is happy.

But then another customer asks for docs. So you tweak what you made for the first customer. It's faster this time. But now you've got two sets of 'personalized' docs floating around. Both with customer-specific examples, wording, and branding. And just like that, you're accumulating a different kind of debt. Not technical debt—documentation debt. A mess of reactive, one-off documentation that isn't scalable, isn't repeatable, and isn’t part of the product you're building.

Meanwhile, you're still sprinting. Shipping features. Fixing bugs. Reacting to feedback. Then someone asks: "Should we update the marketing site?"

Cue the awkward silence. When was the last time you touched that thing? The site doesn't reflect half of what you've built. The messaging is stale. The product has evolved but the way you talk about it hasn't. You have marketing debt. But your team is focused on the actual product. Who even owns the marketing site? How would you resource a refresh? You're already behind where you thought you would be at this point. Can you afford to take folks off your actual product to work on these other things?

The Better Question (As We Came to Learn) Is Can You Afford Not To?

Your docs, your marketing, and your application are all competing for attention. When we treat the application as our actual product, guess what wins? Every time. But customers need to find your product (through marketing). They need to understand how your product works (through documentation).

It's like IKEA building amazing furniture but having no stores, no website, and no instruction manuals. The furniture might be incredible, but who would know? Who would buy it? Who could build it? IKEA's product isn't just the furniture. It's the entire experience.

What past startups have taught us is these other things aren't really "other things" at all. Your docs, your marketing, and your application should all be products in their own right.

We’re not exactly breaking new ground here. Just look at Stripe—their docs aren’t an afterthought, they’re a product that developers love. And PostHog? Their website isn’t just about selling PostHog—it is PostHog. These companies don’t treat docs and marketing as side projects. They treat them like first-class citizens. Like products. Because they are.

So our thinking started to evolve towards having three separate products at HappyHQ:

Marketing: How we tell users our story
Documentation: How we educate users
Application: How we solve their problems

But something felt off with this approach. We would now have three products. Having one product is hard enough, now we have 3x that. How do we organize around these three products? How much time gets allocated to each one? What wins and loses in a crunch?

If we treat them as separate products, we will immediately be back to making prioritization decisions between them. This may still be an improvement on the status quo, but we're not really solving the root problem. We are recognizing Docs and Marketing as products, but they are still competing with the Application. And in almost every startup, the Application wins.

This reminded us of how software teams used to be structured. Remember when everything was siloed? The Backend Team. The Frontend Team. The Design Team. Infrastructure was... somewhere else. This fragmentation led to a lot of issues. Awkward handoffs. End results that didn't quite work together as a cohesive whole.

Modern software teams fixed this by combining these functions into a single unit - pods, squads, tribes, or whatever you call them. These teams are cross-functional for a reason: the outcomes were better when you brought functions that depend on each other together.

Then it clicked. What if we applied this same thinking to our product?

Instead of having three products, we have one cross-functional product. When we ship features, we're not actually feature complete until it works AND we can (1) tell customers about it and (2) help them get the most value out of it. Marketing, Documentation, and the Application - these are all part of the same product.

This approach started to feel more natural. There are still things to puzzle out, but a startup having one product they can focus on feels like the right foundation. Startups can get back to doing what they do best: relentlessly focusing on the product. The definition of what that product includes has shifted, but the tactics remain the same. Cut out as much as possible. Remove distractions. Ship a product users will love. Will this approach mean startups ship less raw functionality? Probably. But we believe this tradeoff will lead to higher quality, more cohesive experiences for customers. Less, but better.

So how are we planning to make this cross-functional product idea work in practice?

It starts with being intentional. This blog post is actually part of that process. Writing forces clarity - as I was typing this all out, our thinking became sharper. That's one of the reasons why we're committed to building in the open. When your thinking is public, you tend to think more carefully.

But this idea of a cross-functional product only matters if it shapes how we actually build HappyHQ.

That means every feature we ship has to account for all three functions—the product, the docs, and the story we tell about it. Not as an afterthought. Not as a separate step. As part of the way we build.

We're already baking this approach into our workflows and repositories to keep us accountable. This is how our Documentation ReadMe begins:

We've done the whole docs as an afterthought thing before. It doesn't work. We want to be intentional about how we build HappyHQ. That means making docs a core part of our product from Day 0.

Docs drive how we build, how we communicate, and how we make HappyHQ usable—not just for users, but for ourselves. They’re not a side thing. They’re the thing.

Our Documentation principles at HappyHQ:

If it's not documented, it doesn't exist.

If you build it, you document it.

If it changes, the docs change.

If a feature can’t be explained clearly, it’s probably not ready.

Great docs don’t slow us down. They make us faster, and our product better.

These aren't just nice-sounding ideas - they're guardrails that keep us honest. That first principle - "If it's not documented, it doesn't exist" - is particularly powerful. It flips the script from "we'll document it later" to "it's not finished until it's documented."

But there's another key element to making this work: creating an environment where the "right choice" is the easy choice. This is what behavioral psychologists call choice architecture.

One of the most famous examples of choice architecture involves middle school lunch lines and the choice between salads and donuts. Where you place options matters just as much as what the options are. Kids pick salad more when it's first in line - not because they suddenly love vegetables, but because the setup makes the healthier choice easier.

I saw this play out during COVID when my family bubbled together in Austin. We had a home gym upstairs - no windows, closed door, basically out of sight. Months went by with no one using it. So one day, I moved the equipment to the back patio where everyone could see it through sliding glass doors. That week, every single person used the gym equipment. Not because they suddenly got motivated, but because we changed the choice architecture. It's not that upstairs was too hard, it's just that it wasn't as easy as it could have been.

This is exactly what we need to apply to our cross-functional product approach. If docs and marketing are truly part of the product, they should live with the product. But most companies split these across different repos:

The application repo
The docs repo
The marketing repo

This setup forces engineers to actively go somewhere else to update docs, then go somewhere else again for marketing. It's technically possible, but we're making our desired approach harder. If we want this cross-functional mindset to stick, we need to make it the path of least resistance.

Enter the monorepo.

(Full disclosure: I'm not an expert on the history of monorepos. They gained popularity for plenty of technical reasons - version control, CI/CD, deployments, and other practical eng reasons. But for our purposes, they also seem to be the perfect solution to our choice architecture challenge.)

The concept is simple: one repository, three directories:

www - How we tell users our story
docs - How we educate users
app - How we solve their problems

This doesn't magically solve all of our problems, but it makes our chosen approach dramatically easier to follow. When an engineer is working on the application locally, they're already inside the same repository that contains the docs and marketing site. They can spin up all three with a single command from a single place.

It's the software equivalent of moving the weights from upstairs to downstairs. We haven't forced anyone to do anything - we've just made the behavior we want more natural. The path between "I should update the docs" and actually doing it is now shorter, more visible, and part of a more fluid workflow.

At HappyHQ, we're all about making intentional choices. We're building a platform to help teams be more intentional about how they communicate and collaborate. Helping reduce noise, avoid distractions, and focus on what matters. But that has to start with us - with how we build HappyHQ itself.

Rethinking our product isn’t just a technical shift. It’s a cultural one. It means every person on our team needs to care about our product as a whole, not just the application. It means redefining what it means to ship. It means celebrating documentation as much as we celebrate new features. This isn't always comfortable - we're fighting against years of ingrained habits. In the startup world, docs and marketing sites are treated a lot like how middle schoolers treat salad. A lot of folks simply don't want to work on them. They're seen as inferior to our actual product.

But we believe a more holistic approach will lead to a better product and a healthier team. We’re betting on the cross-functional product as a way to give our users a more complete, cohesive experience. When the way we tell our story, the way we teach our product, and the way our product works are all aligned, users win. They find us more easily. They understand us more quickly. They get value more consistently.

As we put this to the test, we'll learn what works and what doesn't. Our thinking will evolve, and there will be natural forcing functions that require us to revisit our approach over time. But the underlying goal will stay the same: building a quality experience that feels whole and thoughtful from the first touchpoint to the deepest interaction.

If you've been through something similar or see things differently, we'd love to hear from you.

Happy building!

James Philo