Previously
Previously, we discussed how Startups often begin with great ideas and fast delivery but, just as new investment is won (and expectations from stakeholders rise), the Startup finds itself delivering slower, not faster – see How to align your business vision with the technology rollout? It’s frustrating for everyone, and is usually because they fail to link the architecture (and current organisational capabilities) directly to the business vision and delivery strategy. In short, however brilliant the vision is, if that doesn’t translate into clear, actionable steps for your delivery team, you’re going nowhere fast.
#Functional Blueprint
In this paper, we’re going to describe how to fix this. We use an approach we call Functional Blueprinting, which explores the key problems affecting your particular Startup and then works through the Product Architecture, Technology Architecture and your Organisational Capabilities to address these. The goal is to show you what steps you need to take to resolve these key problems in a way that helps you achieve the business vision. In our experience, Startups are often surprised to find they’re working on the wrong things – new features are often a favourite distraction – when the business vision demands something completely different: how your target customer (e.g. a large enterprise) can adopt your solution into its existing ecosystem.
#Functional Blueprint, therefore, challenges the idea that the only way to build a product company is through a top-down approach from vision / idea, to high-level goals, which middle management, project managers, engineers and vendors will understand and embrace. Instead, we argue that this approach leads to roadmaps that are impossible (or at least unnecessarily hard) to action, and that we should instead work back from a successful target release (MVP, press launch, next round of funding etc.), through the steps that help us achieve this successful release.
The #FunctionalBlueprint looks at:
- Product Architecture - what needs to be delivered so that the customer can achieve ‘x’ in this release as opposed to ‘y’ in the longer term?
- Technical Architecture - how are ‘x’ and ‘y’ technically achieved?; Would it be more efficient to have totally different technical strategies, rather than working towards ‘y’ from the outset?
- Organisational Capability - what can the existing staff deliver? What expertise should are needed? How is this affecting the Technical Strategy?
Creating a Functional Blueprint
Let’s assume you have a clear vision for your Startup ideal solution. What does the end result look like? Are you building a new solution or perhaps extending a proprietary one? What’s needed to take the business to the next level / achieve your next round of funding? Does this involve upgrading the technical infrastructure, adding services or technology, or perhaps building a 2nd Generation platform? What skills do you need to achieve this? Is it quicker (and/or cheaper) to buy in specialist skills rather than learn them yourself? If you need to scale your development capability, is there time / capacity to do this, or is a delivery partner more likely to help you achieve your goals?
Looking at your current problems within the context of achieving your ideal solution will reveal areas of overlap among the product, architecture / technology, and organisation. It will also help you to understand how and where to invest the money you have. This investment must be aligned with the business goals. For example, in the early stages of a startup, the business may need to test the market and gather data. It needs small MVPs and will have a budget for each experiment and innovation. Later, it may need to scale some of the MVP on cloud infrastructure, or increase resilience through containerised workloads under Kubernetes. Once it has an established customer base, it may look ahead to a 2nd Generation platform that can more easily be customised to integrate with customers’ existing solutions and security.
So although it may seem logical to doggedly build out your dream platform from Day 1, to survive you may instead have to take some tactical decisions that get you to your next round of funding, knowing that you’ll have to throw away some of the work when you have space to build something more strategic.
Product Architecture
Now that you understand the problems and areas of overlap, we can drill down into Product Architecture: it’s a good place to begin because it is easy to align with the goals of the business. For the #FunctionalBlueprint, we help you understand and make clear the:
- key value streams that are required to achieve the business goals (from a product perspective);
- key value propositions (from a sales perspective) and how these propositions will be delivered to your customer.
At this stage, you are not really interested in the software packages, but the value that is achieved by using the software, and how the customer will realise that value. For example, does your customer have to register to get value from the product, or do they subscribe to services? Are you providing customer support or investing in features that permit self-servicing?
Technical Architecture
With an initial cut of the Product Architecture in mind, our Functional Blueprinting moves to the technical aspects. In particular, you want to understand the short- and long-term technologies to be used. In a monolith, you’d probably define a set of technologies up-front; however, we’re now in a much faster-moving ecosystem of containerised services (as well as SaaS solutions) so flexibility is a must. Instead of trying to solve every eventuality in your first release, what do you actually need now to achieve your key product initiatives? What about any cost of replacing or upgrading that technology later? You may not get every decision right, but you will stick to the business priorities and budgets like glue, helping to manage expectations and improve the reliability of your estimates. Once you can show your thinking for both short- and long-term, it also makes it easier to argue the long-term benefits of investing in particular technologies / foundational services you care about.
Organisational Capability
Now that you’ve thought about what you want to deliver and how you could achieve this, we move what your organisation is currently able to do. Of course, it’s been in the back of your mind when thinking about technical options, but let’s examine (and possibly even segrate) the business domain idea and the engineering domain IP required to deliver it. Usually, these two domains are mixed – who could image home automation through Google Nest without their app? – however, they are separate concerns. For example, whilst the engineering domain wants (and needs) to be aligned with the business domain, the business needs to understand and mitigate against a failure of a particular engineering project or initiative. Conversely, if the MVP becomes a massive success, the business needs to manage its existing and new customers whilst the engineering domain plans for scale-out. Part of this planning involves the people and skills in your organisation, thinking ahead to what is achievable with the people you have, and who you need to bring in if your idea takes off
The Functional Blueprint
We now have a unified view of problems you face, your business priorities, technical approaches, and organisational capabilities, so we can start building out the #FunctionalBlueprint. You could view this as an actionable roadmap for your Product that can take you from your design / ideation phases through to engineering tasks and releases. Everything in the Blueprint is not only actionable (in the sense that middle management, project managers, engineers and vendors can consume it and deliver against it), but also ensures you deliver according to agreed priorities that are required to achieve your vision.
In summary
The #FunctionalBlueprint enables Startups to communicate clearly their vision to all the teams; to express this as actionable tasks in all their Product Backlogs; and to ensure that everyone is working on tasks that directly help the Startup achieve its goals.
In doing so, the #FunctionalBlueprint often encourages you to make key architectural and organisational decisions. It works well both for mature enterprises (where it’s often used before Discovery), and especially for Startups who often have great ideas, but can be hasty in seeking the quickest and cheapest way to make their idea real.
The Functional Blueprint structures the delivery of these ideas, so that when that idea arrives on an owner or stakeholder’s desk, it does so in a form that helps them make a better decision.
#FunctionalBlueprint supports Product Management, which we see increasingly move beyond the business need, and into feature delivery, technology selection, delivery, and even organisation and sales. Product Managers find the #FunctionalBlueprint helpful to balance the technical architecture considerations against the purely functional perspective. Because it shows how the backlog relates to the business idea, it therefore makes it easier for different stakeholders to align on not only the high level business idea, but how that is best realised. This brings both insight and hence confidence when making key investment decisions.
In the next paper, we’ll describe a real-life business case where we applied this approach, including the surprises it revealed and the changes that the Startup took in response.
How to align your business vision
with the technology rollout?
When getting bad news early is actually good news