Transform a large-scale architecture - 4 - get the first product started

 

Get the first product started

This blog is part of the series "Transform a large-scale architecture guide", see:

• Before the landing
• The first 30 days, and the first half year
• Create the vision
• Get the first product started
• Execution and delivery
• Hiring, promotion, and performance evaluation

Finding Priorities

When creating a vision, you need to determine the north star and overall issues in each domain area. However, with limited resources, it can be challenging to tackle all the problems. So, how do you prioritize which issues to address first and which have better return on investment (ROI)?

Conversations with customers can help prioritize concerns, but these conversations may be opinionated. The individuals you speak with are responsible for a business and focus on what's most important to them. While they can provide data and facts, it may be specific to their priorities and not the entire business.

Gathering data and facts from the bottom up can lead to an overwhelming amount of information. However, grouping them together can help identify the most important things for the systems to operate. These may not be the most urgent issues to address, but they are still essential.

Examining how customers and engineers spend their time is another way to gather information on how to improve their happiness. Understanding why they're unhappy and what they're spending time on can provide insights into priorities.

To find the right balance between the most important and most urgent issues, list out all the concerns, examine them with data and conversations, and then use your experience and judgment to prioritize them. List out the most important things and verify with leaders by having a group conversation with facts and data.

Once you've established priorities, allocate your resources in a laser-focused manner. Losing this focus will affect your timeline and patience from funding partners/leadership.

Defining Product Scope

The vision and priorities guide the project's direction, but the leaders have expectations for results within a specific timeframe. While you can define a perfect product that takes years to deliver, business leaders may lose patience and need to see results sooner.

Ultimately, the product should gain a certain amount of market share within a specific time frame. In my experience, for a 2B product, it can be divided into several milestones:

• Proof of Concept/Buy-in from flagship customer (3 months)
• Delivery of the first product and migration from flagship customer (6-9 months)
• Expansion of the product into the market to gain a certain amount of market share (9-12 months)

The Proof of Concept (PoC) can be a prototype or a simple website that showcases the experience. The PoC should define the flow of the experience and how it simplifies customers' experiences.

The PoC should define the scope of each experience and list out the things you will do in the beginning and the things you will NOT do in the first phase. Not defining it well can create high expectations that cannot be delivered later on in the expected timeframe.

The product delivery and migration should correlate well with the PoC. The requirements should be listed out with a risk factor, including the migration. The product delivery will also need to set up the timeline and expectations right, so there is a two-week or monthly reporting. This is the time to create trust and gain support.

Expansion of the product is an iterative process that requires a pipeline of customers, conversations, plans with the customers, and should be added as part of the product roadmap, iteratively.

High-Level Design

High-level design should focus on the domain-driven architecture. Each domain should either have its own logical or physical boundary. There will always be arguments on micro-services or monolithic services. In my experience, each domain or several similar related domains should be a micro-service.

Defining a micro-service will have its boundaries, including security, database, API, CAP, etc. Define each micro-service and what it should and should not be doing.

Defining the key algorithms/user flows that flow through the micro-services ensures major cases will be working well. Along with it, define the major testing cases to verify they are working excellently.

Defining the operating model for the major services, including failure case fallbacks and pre-defined standard-operating-procedures (SOPs) or automations.

Review them with the team all together, brainstorming on each one of them, and making sure everyone understands their responsibilities, scope-of-work, and delivery expectations.

Finally, make a delivery milestone for each one, work as a team, and get started.

Making Trade-Offs

An Amazon quote says "Is this a one-way door decision?" but it depends on the context. For a product owner, the ultimate question for making trade-offs is whether it is a key experience for customers at this phase and whether it correlates with the key concepts.

The key concepts and architecture define the boundary of the ultimate vision and product. The key concepts should be primitive and present from day 1. Adding/changing them will be expensive.

Then there is a domain area for each product to deliver, and there are domain concepts for each. The domain concepts are key experiences that cannot make trade-offs. Then comes the use cases and experiences, which can make trade-offs.

Customers always have ways to get things done, but the key concepts that will affect their core experiences, including security, cost, and simplicity, cannot be sacrificed.

The best way is always that things can be iterated and incremental. Even with small web-page customization, as long as the concepts and flow are there, as more and more customers onboarded, the small customizations will eventually change and it is a low cost.