Scaling Your Software Startup On The Cloud (part 2 of 3)
In part 1 of this series, we explored methodologies and frameworks that I find helpful in building and growing software startups. The purpose of this post is to illustrate how you can apply these techniques to minimize wasted effort and how planning for your software business translates to your cloud infrastructure.
Prerequisites for moving forward
- You have read part 1 of the series
- You are familiar with the frameworks / methodologies we explore below by watching the video links shared in part 1
Setting the stage
The above diagram illustrates key concepts of the aforementioned methodologies. For this post, we’ll have some fun inventing a fictitious online dating startup, and “scale it”. We will illustrate applying these principles and the relationship from company strategy, to product and growth needs, and how they inform our cloud infrastructure design.
Identify problem we are solving, and for whom
Assume you and others are fed up with being lonely, and existing solutions don’t cut it. You’ve been to weddings, too many actually, and you’ve been to bars, and even tried popular apps but still feel like something is missing. You’re passionate about this problem and believe you’re the team to help solve people’s loneliness, including your own. Let’s first analyze the potential strategies of other solutions.
Disclaimer
I have never used an online dating app so am just “guessing” at what features and functionality they include. Using what's on television or in headlines about various popular apps we can pretend to build a competitor. If my assumptions are way off, or if we don’t explore every type of relationship, I ask you to suspend disbelief for the sake of illustrating these concepts.
eHarmony
This service had a theory that by matching based on a scientific personality profile, people would feel less intimidated. Their strategy is by making personality the primary factor, they will attract people less confident in their appearance who are still lonely, capitalizing on an untapped market.
Tinder
This service had a theory that many people were lonely, but not seeking long-term relationships. Their strategy was to become a replacement for casual hookups, and capture this portion of the market.
Bumble
This service had a theory that women would feel more comfortable on a platform if they could choose who they engage with. Their strategy was to let women decide whether to send the first message after a match.
eTumble — NEW!
Our assumption is people are lonely, and that solutions in the market have not yet solved loneliness on a global scale. We believe the winning solution is a combination of all three above. We suspect deep down, casual hookup seekers would prefer having a chance for a deeper personal connection via initial personality match, but females make the choice whether to interact.
Lean Startup practices advise operating like a “grand experiment”, making bold assumptions and then observe (not ask) the behaviors of users, while rapidly iterating. Often we flush out ideas using a “Lean” canvas, but we’ll assume our team has already done that above. Let’s get started!
Starting with a vision and strategy
SWOT analysis
By acknowledging both internal (strengths, weaknesses) and external (opportunities, threats) forces, you can leverage a SWOT analysis to better identify what must occur to succeed.
This analysis informs your product design as you test hypotheses on solving for the inevitable ups and downs. For example, if high user churn is a threat, you may prioritize features that keep people coming back to your platform. Given a weakness was a lack of psychology experience on the team, you know while hiring or attracting advisors, whom to target. If the team has limited experience with competing apps then you know a task is to use them, and go on dates — a win, win.
Define initial strategic plan using OGSM
Early stage, your objective will be to get a minimum viable product (MVP) launched quickly to begin observing user behavior, and iteratively testing hypotheses. In the software world, we often joke that prototypes always become production, despite our best intentions. Investing a few days to brainstorm with your team to document strategies and measures can reduce rework and speed up your product design and development —let’s explore how below.
Notice in the OGSM example above, we already begin to identify our future team, product, metrics, and infrastructure needs. We will need expertise in mobile applications, machine learning, and API development. We will also need language translation, text and image obfuscation, and accepting online payments. For global audiences we need to meet regulatory and privacy requirements, especially in the European Union.
Lean UX
Lean UX is better known amongst product teams, which is where the author Jeff Gothelf had his humble beginnings. The effectiveness of communicating any ideas via hypothesis statements I believe warrants awareness throughout the organization and not just product teams. I think Lean UX belongs with strategy and vision and used all over.
Each strategy, and subsequently tactic (feature), in the OGSM plan above is essentially a hypothesis. The more we phrase our ideas in this structure, the more actionable and focused they become. For example, the strategy that we will achieve our goals by “providing a safer place to interact” could be phrased as:
“We believe that [millions of users] will join our service if [women] [feel safer to interact] with [only them choosing to initiate conversation after matches].”
This translates loosely to “We believe that [business outcome] will be achieved if [user] attains [benefit] with [feature].” as described in Lean UX canvas. I sometimes interchange this format with another defined in “Product Discovery” agile principles, but the premise is the same — structured communication.
You can see the iterative nature of these methodologies as you combine them. If you haven’t already, I encourage you to review the videos about Lean UX in part 1 of this series.
Product design
Relating back to “Lean” principles, once you have bold assumptions or hypotheses about the problem you’re solving, who you’re solving it for, and how you intend to solve it, you must rapidly iterate and test them.
Rather than asking users, it’s always best to observe their behavior to validate your assumptions, which is why launching an MVP is recommended. In a live product, you can leverage A/B test tools or feature flags/toggles as well.
We don’t need all features eluded to in our OGSM immediately to test our theories, but now have a holistic understanding of where we’re heading. Next we prioritize what our MVP must offer to maximize user value as we rapidly iterate thereafter. For this, we’ll leverage User Story Mapping.
User story mapping
What you see above is already version six! Starting with a holistic view, I quickly mapped out the overall user journey. I then shuffled around boxes and reprioritized user stories to identify the smallest amount we could deliver to test desired outcomes for the target audience.
As you test hypotheses along the way, you apply your discoveries and continue to edit these “living documents” in an agile manner, rather than waste time on stagnant detailed specifications.
C4 Model architecture
We now have information to help us define our software and system architecture, yet doing so in a standardized way is often overlooked. Make sure you have a plan (or blueprint) of what you’re building to efficiently communicate with other stakeholders. While UML remains a longtime standard, the lighter weight C4 Model is what I recommend today.
For brevity of this article, we will illustrate a partial example of our architecture for eTumble. Although there are 4 levels to C4, the standard practice is to illustrate only as deep as required; the “Code” level which effectively would be UML notation is usually skipped.
As noted in my disclaimer above, this is a fictitious app and I have never used an online dating service so these are educated guesses to illustrate the process.
Often I’ll begin sketching ideas on paper to think through the design. Once there’s a general idea of what is needed, I list out elements of the architecture to flush out details. For example, we know we’ll need a database, but our strategy implies a global play. We need to decide whether we can begin with Postgres, or MySQL for launch, and how hard it may be later to migrate to a distributed system like Cockroach DB, or GCP’s Cloud Spanner.
Experiencing “writer’s block” sometimes while staring at boxes and lines on a screen, I find using a spreadsheet like below makes it easy to move stuff around or insert rows as I think of more things, before diagramming.
In some apps you can simply copy/paste like within IcePanel, shown below. There is support for Markdown, which is even faster once you’re familiar.
Hopefully this demonstrates how fast you can transfer what you wrote down into a diagramming tool — taking under an hour to produce beautiful diagrams. Imagine engaging with designers and engineers with the designs above, and how much faster (and cheaper) they would be.
Scaling things up
Earlier hints that we would “scale it” meant we anticipate our future needs based on our strategic plan, and our big-picture view illustrated in the story map. I mentioned the AKF Scale Cube previously, and by applying its principles of x-y-z axes, concluded that our global scale and tens of millions of users will need a stateless design, event-driven system, microservice architecture, and eventually multiple teams, with hosting spanning multiple geo regions on a public cloud platform.
- Our x-axis (duplicate and scale out) is accommodated by stateless, containerized applications and public cloud hosting.
- Our y-axis (specialize) is accommodated by purpose-built microservices, triggered either by HTTP/RPC, or by Pub/Sub messages. These also help define how you’ll likely grow your teams, allowing autonomy and loose coupling to own a key piece of value in the system; this often aligns to the baseline UX illustrated in the story map.
- Our z-axis (split similar things) is accommodated by regionalization. We don’t address this fully in our fictitious example. Let’s assume given global strategy that jurisdictional constraints on systems and data sovereignty, foreign currencies, languages, and future channel sales go-to-market (GTM) strategies may all influence how we scale out this axis. It could even be based on where we find/afford talent for our team, or even as “Team Topologies” describes, the cognitive load of the team.
We fast-tracked this process by making assumptions how to solve for scale in the architecture above, but it depends on your team’s experience designing large distributed systems. We’ll explore this further in the next part of this series when we dive into the technical infrastructure design.
What we’ve learned and built so far:
Time spent so far designing eTumble, our fictitious online dating startup:
- Lean [Startup | UX] canvas — we didn’t illustrate it, but normally this is the point you begin to write what problem you’re solving, who you are solving for, and benefits/value you offer. You might validate your idea with a “smokescreen MVP” and a landing page, for example. Watch the videos in part 1 to learn more.
- SWOT analysis — we identified positives we wanted to exploit, and negatives we need to solve for, informing our OGSM plan. (30 min; expect several hours)
- OGSM plan — we identified key features, technologies, metrics and team we’ll need to implement our strategy, informing our story map. (1 hr; expect 1–2 days)
- Story map — we organized and prioritized user stories, identifying our MVP candidate, informing our holistic architecture as illustrated above. (3 hr; expect 1–2 days)
- C4 model architecture — we identified systems, databases, and components needed, informing our infrastructure required. (3 hr; expect 2–5 days)
How long it takes depends on your experience and the complexity of the system you’re designing. For some illustrations I used a free online tool called Excalidraw that you’re welcome to copy and use. I also encourage watching the videos introduced in part 1 of this series to further explore user story mapping and C4 model architecture.
Fueled with these “living documents”, our team and stakeholders now have a shared understanding of why we’re doing what we are doing, how we plan to win (or at least theories to test), and what we are going to build to solve the big-picture problem.
Investing this time to collaborate and write things down also simplifies the process of designing cloud infrastructure, source code repositories, and the monitoring / metrics we’ll need to eventually support eTumble. We’ll explore this and more in part 3 of this series.
Thanks for reading so far, and I hope you enjoy a more technical deep dive in part 3.
