Being faced with a product team demanding the launch of their minimum viable solution asap, and a sheet of paper that’s blank apart from the heading “Technical design” can be pretty daunting. The stakes are high, because the earlier the technical decision, the higher the cost of getting it wrong.

Here’s a simple approach to thrash out an initial view of a technical solution in conjunction with a product team, which is quick and works well to get things started.

It’ll quickly get you a sense of the objects that your product will need to consist of, and the services it will need.

There are other more in-depth, sophisticated approaches and frameworks - but their comprehensiveness is offset by their complexity and cognitive load.

The emphasis here is on “quick” and “high-level”: jumping straight into a €€€M project with a team of hundreds off the back of this analysis alone would be brave - but the hard part of getting started on a green-field product is the first initial understanding of what you need to do, and this approach can help with that.

It’s got two stages

• Mapping out an end-to-end journey through your product or service
• Using simple grammar to reveal the detail of the system that will be needed

Mapping the end-to-end journey

What you’re looking for here is a path through the product or service that starts with an unmet need, and ends with that need being resolved. You’re looking to strike a balance between something that’s as comprehensive as possible, but at the same time is as simple as possible too.

Yes, those are contradictory. So what you’re balancing is the comprehensiveness to get a representative sample of the objects, entities and services that you’re going to need to build; with simplicity so you can get end-to-end in the first place, but without getting bogged down in edge-cases and details

In the future you definitely will need to think about edge-cases and details: but not just yet!

An example makes this easier to grasp. Think of the basics of an online shopping experience. It probably looks something like this:

• Find the site
• Browse a selection of products in the catalogue
• Add an item to a shopping cart
• Checkout
• Pay
• Get an order confirmation

There’s obviously a lot this flow doesn’t explicitly cover, for example:

• Searching
• Registering an account, or logging in
• Adding payment methods

That’s to say that these things won’t be important if you’re trying to build a full-service experience - but there’s no point in being able to register an account or add a payment method until the basic features are in place.

That’s the core of the minimal minimum viable product approach.

Nouns, adjectives & verbs

Now that you’ve got a first flow, you can use this to start to come up with the initial design.

You’re going to do this by examining the flow and looking for the nouns, the verbs and the adjectives that are needed to describe it.

Start with NOUNS.

These are likely to be the objects that your system is going to need to deal with.

In our e-commerce example, it’s things like product and catalog and cart and payment

All of these are nouns, and there is a good chance that you’ll have a reasonably accurate picture of the system you’re going to build if you think of these as the objects that your system will manage.

In later stages, nouns also hint towards the kind of data that your system will be filled in - so a quick sanity check if you’re unsure about whether it’s a noun you need is to ask yourself “Can I imagine needing to get a report on this?”

Being able to view all the products in your e-commerce system is a pretty clear use-case, so that’s a good indication that you’re on the right track thinking about a product object.

Next, look for ADJECTIVES

In our e-commerce context, it’s reasonable to assume that products can be described in terms of price and size and colour and so on. Grammatically-speaking, these are adjectives.

These are likely to become the attributes of the objects that you identified earlier. Most products need a price, and that’s usually stored as a floating-point decimal value - there’s a hint about both the way you need to model your products, and also potentially information about the technology you could need.

Another possibility is that adjectives might “hide” further nouns - for example, you could model size as an attribute. It might also be possible to describe it as size objects with dimensions in their own right - a “large” object with height and width and depth values.

The point at this stage isn’t to nail down every last detail, but use what you come up with as a signpost to more detailed design that you will need to do at a later stage.

The final stage is finding the VERBS.

In our e-commerce scenario, we’re going to want to do things like open (the website), search (for a product), add (the product to a cart), checkout, and pay.

This gives you a hint at the kinds of services and components that you might need to build or interface with:

opening the website implies that you’re going to need a webserver (this is a requirement that seems obvious when you read it, but it’s easy to overlook these kind of low-level infrastructure requirements) searching for products will need an indexing service and a search engine checkout and payment imply a need to build cart management features, and integrate payment gateways

Keeping it simple

At each stage of identifying nouns, adjectives and verbs, you’re probably going to come across questions that start with “but what about…?” The temptation here is to go off down rabbit holes of detail - “won’t customers will need accounts in the system before they can checkout?”

The obvious answer here is “yes, they probably will” - but that’s risky at this stage. Remember that you’re not designing the entire system here - this is a lightweight process to get you started. It’s more important to get an end-to-end happy path through the process first, and then start to think about supporting scenarios and edge cases and exceptions.

As you iterate through the flow, you can add detail - but start by getting a good understanding of what lies at the core of your minimum viable product.

What comes next

At this point, you’ve got

• a representative end-to-end flow for a piece of your product’s functionality
• an initial inventory of the objects that this flow will need
• an idea of how to begin modelling those objects
• the services that may be required to move the objects through the flow

This isn’t the end point, of course - so far you’ve still explicitly ignored those important factors like how to handle edge cases and other supporting functionality such as users and accounts.

But what you have got is an initial flow and high level design that you can use for multiple purposes:

• creating early-stage prototypes as demos or proof-of-concepts
• narrowing down technology choices, and getting a sense of required infrastructure
• a basis for further refinement to add detail, supporting functionality and thinking about how to handle edge cases

This approach isn’t a substitute for more formal design processes, but conceptually it’s easy enough for almost anyone to get involved with; and doesn’t require specific tools or training.

Sometimes simple is good enough, and a minimum viable approach can be the way to uncover what will be your minimum viable product.