In this paper we look at the thought process during a #FunctionalBlueprint engagement, and the outcomes and benefits the client experienced. For confidentiality reasons the real names of the companies and solutions have been replaced, we will call our client Growth Group.
Background
Growth Group is a B2B2X startup company in the FinTech industry. It has Series C funding which it wants to use to deliver its FinTech solution to SMEs. These SMEs could come from different industries, because the FinTech solution is all about making it possible for those SMEs to deliver financial services to their own customers. These split into “core banking”, which can be seamlessly integrated into the SMEs’ existing digital offering to give better insight and traction with their customers; and “new services” for the particular vertical that SME operates in. These new services will eventually be hooked into the “core banking” services enabling a much wider offering to customers. This could be anything from a large supermarket offering banking linked to its loyalty card, to a travel company that extends its marketplace of restaurant and hotel bookings into taking payments without losing commission to existing on-line payment providers.
To grow, Growth Group has to increase the volume of SMEs and merchants that are leveraging their FinTech platform. There are two ways to do this: make it easy for financial services companies to adopt its solution and use it to onboard their own merchants; or extend the Growth Group solution into a platform that allows them to onboard merchants directly.
At the time Estafert was introduced to Growth Group they had already decided to co-invest in a startup company, which we’ll call TravelLux, which specialises in luxury travel. TravelLux had already developed a catalogue platform to allow luxury-seeking travellers to select various services to book accommodation. Growth Group’s goal was to get a marketplace solution to MVP, and make this available to merchants using the full FinTech solution.
Building the Functional Blueprint
You’ll remember from previous papers (Link 1, Link 2) how the Functional Blueprint challenges the idea that product companies can only follow a top-down approach from vision / idea, to high-level goals, because, in our experience, this is insufficient to build an actionable roadmap. The result is that delivery teams end up misaligned with the business goals leading to slower releases and frustration with stakeholders. Instead, we start by looking at the key problems faced by the startup and then explore Product Architecture, Technical Architecture and Organisational Capabilities to resolve them.
- 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?
Key Problems and Product Architecture
The first problem Growth Group had hit was whether to use (and extend) an existing marketplace platform, or do build one from scratch. As mentioned earlier, by the time we applied Functional Blueprinting, they’d already co-invested in TravelLux and its platform. So the first decision we saw them make was how best to approach the marketplace solution. They had three options:
- Leave the development of the marketplace solution to TravelLux. This would minimise the risk but also any control over the solution.
- As per 1, but providing product and business management expertise (around the FinTech elements).
- The reverse of 2: Growth Group would provide funding, product vision and management and engineering capabilities, whilst TravelLux would contribute its own (travel) business domain expertise but also access to its customer base.
The Business Goals for Growth Group aligned with a Product Architecture where the FinTech solution (e.g. booking) was core to the marketplace offering. It therefore went for 3. so that it could realise its goals and potentially exploit the new customer base.
Technical Architecture
Given the decision to take ownership of the marketplace platform, we then had to look at how to deliver it. Clearly, there was an opportunity to extend the existing TravelLux platform, but also options to buy or build a different platform, still leveraging TravelLux’s domain expertise and customer base.
The Functional Blueprint team raised a number of questions to help Growth Group think about both short- and long-term implications: how well does the TravelLux solution align with Growth Group’s vision of a merchant ecosystem using the new marketplace platform?; how well does the architectural roadmap to support these short- and long-term goals?; and how does this co-investment fit into the wider Growth Group business goals?
Growth Group was pretty clear about its vision for the marketplace and set about defining high level requirements for it, along with an initial technical architecture and delivery process, and a target resource plan. It was clear from this that the TravelLux marketplace was completely different from Growth Group’s FinTech solution, moreover, Growth Group lacked the product architecture, blueprints, and technical expertise to build the new marketplace solution that was needed. This was a really valuable exercise as many companies in Growth Group’s position would have spent months or even years trying to knock TravelLux’s solution into the shape they needed with no guarantee of success.
Organisational Capability
Realising it did not have the answers, we returned to another concept within Functional Blueprinting, the separation of business from engineering concerns. Once we accept that the engineering team is self-contained and aligned to the business goals, we can revisit the “who should build it’ question. Is there value in being a technology partner in this, or should Growth Group revert to supporting TravelLux building it (option 2, earlier)? Is it cheaper / more effective to outsource the engineering to a delivery partner with experience of developing B2C travel products? And how should the marketplace solution be brought into the Growth Group ecosystem as it is developed?
The Functional Blueprint
It seemed like we were going in circles, but in fact we were just iterating towards an approach that aligned the business vision with the Product Architecture, Technical Architecture and Organisational Capability. We were now looking at costs for bringing the end-to-end solution into a continuous ecosystem and how those could be met using the planned business expenditure. Because we’d also done work on the requirements and architecture of how to achieve our MVP including possible use of SaaS solutions for certain generic features – we knew SaaS would lower short-term costs and reduce time-to-market, but also require replacing in the longer term.
Our Blueprint therefore began with some key problems Growth Group were facing, helped them evaluate what was important to achieving their business and product goals and aligned a technical strategy that would fulfil this. From it we gained the following insights:
- We produced a conceptual model of the Product Architecture. This showed us the key value streams including how value is delivered to the customer. For example, “Booking” is a clear value-add to the TravelLux platform, but how is that value delivered to customers and what mechanism is required to support the best booking experience we can give? So whilst the technical aspects are important we could evaluate the TravelLux platform by how well it aligned to Growth Group’s product vision, product and architectural roadmap. Once we knew what we were optimising for, we could focus on how to build it.
- We found fundamental differences between the Growth Group target business architecture and the existing TravelLux one. For example, the TravelLux business was constructed around providing a content-oriented approach to the marketplace (where the end-user searches for the right product and service), whereas Growth Group envisioned a behaviour-oriented approach where the products and services are recommended to the user.
- We enabled the product and engineering teams to look at the business requirements from a functional breakdown perspective. This improved the MVP scoping exercise by providing valuable insights into the depth and the interdependencies between business requirements.
- Understanding the value streams (and how they relate), helped align investment to the existing core business and optimising the costs. It meant we could consider SaaS providers because we knew what was core to the business and what could be replaced later.
- As we gradually revealed the engineering practices and patterns, we could separate them from the business domain. This helped support best practice (and centres of excellence) within the engineering domain such as such as the development of microservices or maintaining cloud operations or automation testing. These divisions would naturally know and own your engineering IP which can be translated and reused in new initiatives.
- The process enabled Growth Group decision makers to rationalise the organisation alignment between the two businesses. The mapping outlined both the risks and opportunities in undertaking the product development of a new platform.
- Organisation capability evaluation was the key factor in technical stack choices for the areas in the product development, built in-house, and the definition of the respective processes and procedures.
- Combining product architecture with organisational capabilities gave us one of the key moments for Growth Group in that it answered the question of how to build the marketplace solution and what type of delivery method was needed. Growth Group had an API-first approach but what became apparent from this analysis was that they needed to adopt a front-to-back delivery model. Because we could give Growth Group a holistic understanding of this initiative, they made sure the decisions taken were well-informed with a direct effect on the delivery.
- The unified view provided by the #FunctionalBlueprint identified user experience combined with premium branding and content as cornerstones of the MVP. The front-to-back delivery model emerged as the preferred choice from the #FunctionalBlueprint as it aligned the technology investment with the business strategy and de-risked the overall project delivery plan. Unveiling the working product from the very beginning also helped early user testing and feedback.
- The objective and systematic approach helped stakeholders overcome some gut feelings and subjective sentiments by providing specific facts and insights
- All the stakeholders agree we saved significant time and costs. They recognised that they could have tried the platform out for a few months before reaching the same conclusions.
- Understanding what the requirements and value streams were, gave Growth Group confidence to outsource parts to a delivery partner.
- The clear architectural approach led Growth Group to select the best technology and architecture for getting the job done – not necessarily the “best” tool, but the “right” tool. For example, Growth Group selected a new technology ecosystem based on node.js as it had superior performance combined with lightweight CI/CD tools.
- The FunctionalBlueprint illustrated that the MVP style of delivery approach, combined with the engineering capabilities and the scenario evaluation confirmed to be best aligned with the centre of excellence that they had in their own organisation.
- Lastly, related to the productivity guide rails, Growth Group were able to find their sweet spot where their teams and processes work perfectly and smoothly. They decided to structure their delivery process around their current best practices.
Summary
Startups face many challenges in building not only their vision, but also delivering it whilst winning successive rounds of funding. The Functional Blueprint approach helps Startups understand where they are and what they need to do to ensure their Roadmaps are deliverable and actionable by all who use them. The case study above some of the thinking that happens within these engagements, especially the focus on key problems, Product Architecture, Technical Architecture, and Organisational Capabilities. Of course, each Startup is different. It also shows that the insights you gain are not necessarily those you’d expect – at the outset, everyone thought TravelLux’s platform would be the answer to the marketplace solution, for example. We enjoyed this relatively short engagement with Growth Group. The feedback we received was that it was high value at relatively low intervention and saved them considerable time and effort. They are now building out their marketplace platform with the next release due this week.
How to align your business vision
with the technology rollout?
Achieving your Product
Vision Quickly and Sustainably