Community Startup - Open Engineering Strategy

Goal: Prove Product Market Fit with an MVP

May 15, 2022

https://github.com/aleixmorgadas/awesome-engineering-strategy

We all talk about strategy, but very few we can share them publicly.

The main reason is that a Strategy contains business risks, opportunities, and other critical information that your competitors might use. It’s normal that those documents not to be available publicly.

Another reason is that we might not know how to do strategy, and we don’t want to look stupid.

I questioned myself for a long time.

Am I doing strategy right? How others are doing this? why do they look so confident? I’m missing something.

The truth was, we all were making it up as we go 🤣

That’s why I did my post series about Designing an Engineering Strategy. I wanted to share the method I’m using after failing on Strategy for several years.

Today, I want to share a real application of the Designing an Engineering Strategy for a product I worked with.

Context

The product isn’t available due to we didn’t prove Product Market Fit with the MVP, and the decision was to discontinue it 😞

Yet, the Strategy we took it’s relevant to share with others in similar situations 🧡

⚠️ I’ll not use the specific case of the company and product because I want to make it a little more abstract to fit more use cases; otherwise, I would need to explain the whole company context, and we will be missing the point.

Business Hypothesis

As with any early-stage startup, you have a lot of assumptions and very few facts. You need to be comfortable with the uncertainty and take risks to find the information to help you know if you’re going in the right direction.

A well-known approach to do it is by using an MVP, and an MVP needs to provide:

A business-hypothesis. What do we want to prove? What do we want to learn?
A user-persona. To whom we are doing this?
A set of features. What will we deliver to fulfill the user needs?
Metrics to prove the business hypothesis. Which numbers do we need to have to prove that our business hypothesis is right?

Let’s consider the next generic business hypothesis that could suit several community/social-network startups:

We consider that exists the need for a place for the community to talk about and share their experiences for X topic (assumption).
By providing a web application that suits the user needs (MVP), we will measure (numbers made up):
At least N accounts registered
5% Accounts Create Content
15% engagement by other’s users
S% internal searches
(business hypothesis validation)

High-Stake Business Problem

From Business Hypothesis to Engineering Strategy

As I share in Designing an Engineering Strategy Part II, in creating an Engineering Strategy, you need to understand the business first.

To understand the business needs, we ran a Lean Inception Workshop with all the team. Lean Inception says:

Think Big,
Start Small,
Learn Fast.

Lean Inception is a good method to align people and build the right product. After the workshop, you have a good understanding of why you want to build this product, what needs to be done, and what we need to measure to prove the business hypothesis.

After that point, we were able to Design our Engineering Strategy!

Analysis

ProductTech Team Size

1 Product Owner
1 Product Designer
2 Full Stack Developers

There was no intention to scale up the team until Product Market Fit was accomplished or we had a good insight that we were going in the right direction to start a bigger founding round.

Need for fast experimentation

We identified several assumptions meanwhile the Lean Inception Workshop, which translates to we need to be flexible on the solution, we shouldn’t go deep into the business domain until we prove the need, and we need to adapt fast as we learn along with the users.

Technologies

The team was comfortable working with React, Django, PostgreSQL, and AWS. No need to change the technology stack.

🚧 We had a previous product built on that stack, thinking of reusing the same monolith for a new product. This could help us reduce the Time to Market by not redeploying a new service but reusing the previous.

We took into account maintainability. We don’t want to create as much as systems that later will lock us down to them and be slower due to premature early decisions.

Measuring

We had Google Analytics in place for the inbound marketing and user behavior. We considered using Mixpanel to have a more curated analysis of our users and be able to learn from them faster.

Understanding the Landscape with WardleyMapping

To understand our landscape, we thought about the user needs and how they are being solved in the industry.

We were able to place them in a Wardley Map, and we identified that most of the social part of the product was already solved by SaaS products. We wanted to identify what’s not solved and needs to be custom-built and what we can externalize.

Lucky for us, we found that the more tedious part, we could use GetStream for our solution. 🚀

DDDing with Bounded Contexts and Subdomains

Combining multiple tools to understand our product can drive better outcomes. That’s why we also used some patterns of DDD to understand our Business Domain.

Using DDD, we identified a similar scenario with Wardley Mapping. Probably you’re already biased toward a problem understanding, but it’s good to have another perspective and challenge assumptions.

We used the core-domain-charts technique to identify the higher business differentiator and the supportive models.

An MVP should aim to be as simplest as possible. That’s why we have only two subdomains 😄

At the end of the analysis, we concluded that we have the company bounded context with two subdomains:

User Profile. Our core domain where we have more business differentiation
SocialFeed. Our supportive domain that we need to offer the community/social network capabilities, but they don’t offer any business differentiator nowadays. We need to externalize this one as much as we can.

Direction

Our Engineering Strategy direction is:

Make heavy use of external providers and solutions to leverage our product without creating custom solutions where we cannot compete; neither by business diferenciation nor at cost.
Our MVP needs to be constant adaptation based on:
Learning meanwhile delivering with our users.
Deploy rapid adaptations as we learn from our users.

Coherent Actions

Heavy use GetStream

Building a social network-like solution might consume all the company resources. We must not take that path. We’re not innovating the social network ecosystem. We are filling the need for a community to have a space to talk about X topic.

We will leverage our product features up to the getstream features.
We will not customize their product.

Deploy aggressively, recover fast and externalize brutally

We need the shortest deployment cycles and infrastructure maintenance, so the developer team focuses on the product and not infra.

Heavy use AWS products.
- ECS Fargate to deploy our monolith
- RDS as managed PostgreSQL service
- DynamoDB and Lambda to record events. See code here
Automate repetitive work as much as we can.
- GitHub Actions with Continuous Delivery Pipeline
- Terraform for IaC
Heavy use of Django and Django Restframework build-in solutions
In case of doubt, do a CRUD without logic until proven to be needed

Feature Flags for rapid experimentation

Use a Feature Flag system, like split.io, to leverage rapid experimentation safely.

Measure

Measure as much as we can about user behavior with Mixpanel. Each interaction that can help us validate our business hypothesis must be measured.

How did it go?

We couldn’t prove or dismiss our business hypothesis based on user engagement. BUT! We proved that running a custom solution to serve a niche community was more expensive than anticipated.

In terms of timings: