The existing business always has a good reason to come first.
A customer is waiting on a feature. A platform update needs attention. The backlog is full of improvements, every one of them attached to a product that already earns money. A new venture has to compete with all of that before it has earned its first dollar.
Sometimes the opportunity arrives on its own, when customers start using your product in a way you never intended. Sometimes you go looking for it, because the business is healthy but another year of improvements is unlikely to produce outsized growth. The next business might serve more of the same customer’s needs, or it might take you into a different market entirely. Either way, waiting for spare capacity is not much of a plan.
I have done this twice, from opposite ends of the size spectrum. At Orbit, we built Alliance Pro alongside a portfolio of established Shopify apps, which meant stretching a small team. Earlier, after selling LemonStand to Mailchimp, I helped develop a new commerce offering inside a much larger company, which meant getting a large organization to give a new team room to operate.
Both required more than a promising product idea. We had to decide what deserved funding, who could make decisions, and when the evidence justified doing more. What follows is how we worked through those questions, and what I would tell another operator facing them.
1. Follow the work beyond your product
I didn’t know pro programs existed when we first ran into them. Jamie, our product manager, did: he volunteered in search and rescue, and some of the gear he used came through programs like these.
We found outdoor brands using Wholesale Hub, our wholesale app, to give qualified members access to discounted gear. These weren’t wholesale buyers. They were people whose work and interests made them valuable advocates for the brand.
Interviews revealed programs with tens of thousands of members, administered through a surprisingly fragile collection of tools. An application came in through Typeform. Someone checked credentials and updated a spreadsheet. Approval meant handing out a promo code, tracking it, and making sure it expired. When membership came up for renewal, much of the process started over. Codes leaked. Information had to be re-keyed between systems. The people whose job was to build relationships with members were spending their time administering discounts instead.
Wholesale Hub solved one part of that job. Across interviews with existing customers and with brands that had never used our software, we kept finding people stitching the rest together themselves.
That argued for a separate product rather than a feature. The pro program was a distinct customer job, with its own workflow and its own reasons to buy, and a wholesale feature would have addressed only a piece of it. It was also concentrated on a particular market vertical: outdoor gear brands.
Orbit gave us a real head start: early customers, Shopify expertise, and functionality we could reuse. What it did not give us was a market. Most customers of our other apps had no need for Alliance, and we still had to learn who ran pro programs, who controlled the budget, and how to reach them. Corporate Explorer draws this distinction well: an established company can supply valuable assets, but the internal entrepreneur has to put them to work.[1]
So be specific about what you can actually borrow. A customer relationship might get you a discovery call without getting you to the new buyer. Shared code might shorten development without helping you sell. A large audience only matters if you can reach the relevant people with an offer they need.
Ask customers to show you the whole job, not just the part your product handles. Follow an application, an order, or a report from beginning to end. Where do they copy information? What goes wrong? What does fixing it cost? A recurring workaround is worth investigating when it points to a problem people will pay to remove.
2. Fund the next decision
Our first investment in Alliance was a short product pitch and some mock screens, followed by clickable prototypes. We showed them to people who wanted a better way to run their programs, and their reactions helped us refine the proposition before we committed much engineering time. Then we built in small increments: a few weeks of development, more feedback, another decision. As confidence grew, we took on longer blocks of work.
I could authorize all of this while staying within Orbit’s profitability expectations. Spending that reduced earnings would have required agreement with Tiny’s CEO, and I didn’t think we needed that to get a first version into customers’ hands, so we reallocated the team we already had. That kept payroll unchanged. But that did not make Alliance free. Every week spent on it was a week unavailable to an established product.
Preserving margins should not be a universal condition for starting something new, however. A credible opportunity can justify lower earnings today. The obligation is to protect the company’s long-term viability, not every percentage point of this quarter’s profit.
The harder question is how much. Set the ceiling before the budget: the amount you could lose outright, and would be willing to, without putting the company or its existing customers at risk. Sarasvathy’s research on expert entrepreneurs calls this affordable loss, and it is a more honest starting point than expected return, which at this stage is mostly invented.[2] At Orbit, my ceiling was the most I could commit without going to Tiny for approval: the team’s time, and nothing that reduced earnings. A ceiling that includes cash and headcount changes what you can spend, not how you decide.
Inside that ceiling, start with what would make the business worthwhile. How many customers could you realistically reach? What might they pay? What would it cost to sell to them, onboard them, and support them? And which single assumption, if it proved wrong, would make the whole proposition unattractive? That is the discipline in McGrath and MacMillan’s discovery-driven planning: expose the assumptions and test them before committing heavily.[3]
Then size the stage to that assumption, not to the ceiling. Decide what result would justify a larger commitment, whether a number of paying customers at a given price, a migration by a prospect who controls budget, or a renewal after the first term, and fund the cheapest way to get a clean read on it within a few months. The budget is whatever that costs. The test need not be another feature: if the uncertainty is willingness to pay, a pilot approved by a budget holder tells you more than a more polished demo; if it is willingness to switch, watch what happens when a customer has to migrate. Expressions of interest and commitments answer different questions.[4] If no affordable test can move the assumption that matters most, you have your answer before spending anything.
Write the decision rule before the results exist. State what continuing, changing course, and pausing each look like, with thresholds, because once the numbers are in, everyone argues from the result they wanted. We never wrote ours down at Orbit; each funding step was a judgment call, and it would have been a better one with the thresholds on paper. If the plan reduces earnings, agree it with whoever owns the P&L in advance, with a date for review. A planned investment and a missed quarter can carry the same dollar figure and mean completely different things.
Here is the tool I would use to make each commitment explicit. Put it on one page, revisit it at every stage, and don’t let it grow.
| Decision | Questions to answer |
|---|---|
| Opportunity | Whose problem are we solving, and what would make this a worthwhile business? |
| Advantage | Which relationships, capabilities, or routes to market can we actually use? Who controls access? |
| Next test | Which assumption needs testing next, how will we test it, and what evidence would change our mind? |
| Ownership and authority | Who owns the venture, what can they decide, and who resolves conflicts with the existing business? |
| Resources | Which people, how much time, and what spending or foregone earnings are we committing? What is the most we would write off? |
| Tradeoffs | What work will wait, and which customer obligations and operating needs must remain protected? |
| Review | When will we review results, who decides, and what would justify continuing, changing direction, stopping, or investing more? |
We didn’t use a form like this at Orbit; it is what I would use now. It makes the investment explicit without pretending the whole business can be planned in advance, and it gives each stage of funding a place to be argued for.[5]
Fund the next decision, not the whole business. Each stage should buy the evidence that justifies, or rules out, the one after it.
3. Plan around learning time, not just development time
At Orbit, we rarely divided our small engineering team across several products at once. Instead, we used the gaps between shipping something and knowing what to do next.
After a substantial release for an established app, we needed time to see how it landed. Engineering used that window for a bounded piece of Alliance work while support and measurement continued on the other side, and by the time the Alliance work shipped, we knew what the established app needed next. Sometimes that meant two weeks on one product and six on the other; sometimes the reverse.
This worked because Orbit had a portfolio of products to rotate between. A single-product company can run the same rhythm across features, or whatever natural divisions its product has: ship one, let the feedback accumulate, and spend the waiting time on the new venture.
The schedule was deliberate but not sacred. An urgent Shopify compatibility requirement pulled us back to the larger app. A production issue in Alliance interrupted work in the other direction. Both had customers depending on them, so we stayed close to early customers, shared our priorities, and explained changes rather than promising roadmap dates we could not guarantee.
You do not need to copy that rotation. You do need to distinguish ordinary backlog pressure from a legitimate interruption. A venture that loses its team every time the existing business asks for something has a mandate on paper and no funding in practice.
4. Give someone the authority to move
Mailchimp had far more resources than Orbit. At first, that did not translate into progress.
After acquiring LemonStand, the company tried folding us into existing teams in a matrix structure, where people report to one manager but take direction from several. We were supposed to help create a new commerce offering, and we found it difficult to get a whole new initiative moving inside that arrangement.
Things changed when I became Head of Commerce, reporting to the chief product officer. I had weekly conversations with Ben Chestnut, the CEO, and with Rick, the CFO. Bruce, our CTO from LemonStand, led technical decisions; I led product decisions. We still collaborated across the company, but now there was clear authority and a direct route to resolve obstacles. That was the structure under which we began conceiving Mailchimp Stores. I left before the full launch, but the difference in our ability to get started was substantial.
O’Reilly and Tushman’s research on organizational ambidexterity describes this balance: give exploratory work its own ways of operating while senior leadership keeps it connected to the established business.[6] The practical requirement is simpler than the name. Someone must be able to set priorities, commit resources, and settle conflicts with the rest of the organization. In a small company, that may be the CEO directing a shared team. In a larger one, it may require a dedicated group and an executive sponsor.
Telling a team to act like a startup accomplishes little if every important decision still belongs to someone else.
5. Watch what customers commit, not just what they say
Our early customers imported their members, configured emails, customized application pages, and moved entire pro programs onto Alliance. Some then expanded across regional stores. They were trusting it with work that mattered.
OneUp Components, our first customer, went further and produced its own video testimonial, complete with mountain-bike footage. We supplied the questions; their team did the filming and editing. It gave us a useful way to show other brands what the product could do.
One prospect was Full Stack Supply Co. I reached someone on its marketing team through LinkedIn with a short pitch and the OneUp video, and Jamie and I gave them a demo. Then they showed us their system. They had spreadsheets, Zapier automations, and other tools working together, and they had clearly put thought into automating it. But the process was still fragmented, and managing promo codes remained a headache. The demo made the difference visible: applications, approvals, access, and communications in one place inside Shopify. They started with one brand. After using it, they brought others over.
That progression mattered more than any reaction to the demo. They had seen the product in their own operation and chosen to rely on it more.
About a year after our commercial launch, Alliance reached a six-figure annualized revenue run rate. That was the point at which I was willing to say we had product-market fit in our target segment. Customers stayed, expanded, left strong reviews, and referred other brands. We also had a low-volume outbound process producing customers, with records of outreach, responses, and conversions.
Six figures was not a magic threshold. It was simply where enough evidence had accumulated for us to back a larger sales effort. I think of fit as a degree of confidence rather than a certificate you earn once and keep. Retention mattered, but so did the reasons for it: customers were happy and recommending us, not merely reluctant to endure another migration.
Look for commitments, not compliments. A migration, an expansion, or a referral tells you more than any reaction to a demo.
6. Be willing to outgrow the scrappy version
By the end of my time at Orbit, monthly recurring revenue growth was accelerating, and the next constraint was consistent sales effort.
Jamie and I could win customers. What we could not do was prospect, follow up, and run demos every day while doing our other jobs. We needed more dependable sales capacity, and I left as we were working on that next step, before we had scaled outbound.
This is another investment decision, and it deserves the same scrutiny as the first one. A couple of people doing everything may be exactly the right arrangement for learning whether a business can work. Keeping that arrangement after it becomes the constraint is not capital discipline; it is inertia.
Before expanding, count the work hidden inside those early sales: research, demos, onboarding, support, and your own time. Then fund the actual bottleneck, whether that is a hire, protected capacity, better tooling, or some combination. Corporate Explorer makes the useful point that a venture needs a path from incubation to scale, including the resources and sponsorship to get there.[1]
Starting small is a way to earn the right to invest more. It should not become a rule against doing so.
7. AI changes which opportunities deserve a try
Building Alliance today would involve a different calculation.
Finding prospects used to take a disproportionate amount of our time. Pro programs went by different names, were often tucked away on a brand’s website, and needed judgment to separate a useful prospect from an outdoor company with no real fit. Research agents can now find those pages, extract evidence, classify prospects, and prepare account-specific outreach.[7][8]
For a similar market, I would use AI in three places:
- Build an evidence-backed prospect list. Record the brand, program page, likely buyer, and reason for fit. Review uncertain cases instead of accepting a spreadsheet of plausible-looking names.
- Prepare conversations and content. Use the prospect’s actual workflow, relevant customer proof, and questions from interviews or reviews. Review the facts and messages before sending or publishing.
- Put a narrow solution in front of a customer. Use faster prototyping to test the workflow that matters, then observe whether someone adopts it. Keep testing and production readiness in the budget; development speed alone is not the whole result.[9]
This changes more than execution speed. It can change which investments are worth considering at all.
In a recent conversation with a software holding-company executive, we discussed why buying an established business had often looked more attractive than building an adjacent product. Internal development could consume months of expensive team time before producing any useful customer feedback. Cheaper, faster experiments change that comparison. A prototype is still not a business with revenue, customer relationships, and operating knowledge, and acquisitions bring those assets along with technical debt and other liabilities. But when you can test a serious opportunity with a smaller commitment, some ideas that once looked too expensive to investigate deserve another look.
The same tools are available to your competitors, which is the stronger argument for moving. A stable business should use its customer access and cash flow to investigate what comes next while it still has the room to do so.
The remaining discipline is deciding what deserves attention. Producing ten demos is not the same as running ten useful experiments. The useful test is the one whose result changes what you are prepared to fund.
Not every week belongs to the existing business
Alliance began with customers using our software in an unexpected way. Mailchimp’s commerce initiative began with a deliberate decision to expand. The two needed different team structures, budgets, and routes to market, but both needed someone to turn an opportunity into a series of commitments the company would actually honor.
For an operator, that is the work: deciding what can wait, what must remain reliable, and what evidence is strong enough to deserve more people, more time, or lower earnings today. The one-page commitment in section 2 is one way to force those decisions into the open, and the test of any experiment is whether its result would change what you fund.
The next venture will be less certain than the business you already have. That is a reason to test it carefully, not a reason to hand the existing business every resource by default.
There will still be a customer request next week. There will still be a release to finish. The backlog will not tell you when it is time to build the next business.
That decision belongs to you.