One Less Boundary Between Engineering, Product, and Marketing

At my last startup, our marketing site and core application could not have been further apart: owned by separate teams and built with separate tools – the division was intrinsic.

When we started the company, we didn't think twice about it: the marketing site and core application would be separate. We'd seen it done that way countless times. We could allocate separate resources to each site, and the marketing site wouldn't drain crucial development resources. It was a no-brainer.

It was a no-brainer partly because we were product-first rather than distribution-first. We figured we'd address the "How do we find customers?" question down the road. We could never have imagined investing our limited development resources into anything but the product.

So, we built the marketing site with no-code tools. It was slow, bloated, challenging to edit, and divorced from our product. At worst, the two sites felt like separate universes, even to users. Any communication between them was rudimentary: URL parameters and page paths. That was about it.

In creating Magical.pm, I'm taking a distribution-first approach – meaning that the priority is finding demand, with core product work prioritized to support demand-gen efforts. In this case, product follows distribution.

Because of this, rethinking the boundary between the marketing site and the core app came naturally. What if that boundary wasn't there? What if my marketing site was my core app, with its functionality, features, and performance?

Without the boundary between the two sites, interesting possibilities emerged. Marketing content and core app functionality could co-exist in harmony.

For example, my Template pages, full of keyword-rich content, include in-page links to the core product. Click "Generate with Magical.pm," and the site scrolls you down the page to the core product, letting you try the product right then and there. It's pretty magical, pun intended.

Or, better yet, this blog post itself. Scroll down to find my core product – an AI product management co-pilot – running with all its functionality intact. Error handling, template selection, and more work on the same page you're reading this article.

If there were an accounting of my development resource allocation, it would show that most of my resources have gone into marketing – in keeping with my distribution-first approach. In that sense, the marketing site is the product.

This style of resource allocation would have been unthinkable at my previous startup. We were product-first. But, in a distribution-first mindset, investment into marketing comes first, and the line between marketing and product blurs.

This approach feels like a superpower – enabling harmony between disciplines that are often oil and water: engineering, product, and marketing.