Here, we’ll examine the role of the solution architect in greater detail.
Let’s dive in!
Table of Contents
What’s a solution architect and why they’re important for product discovery
A solution architect is one of the key roles in the product discovery process.
But what exactly is a solution architect? And why are they important for the success of your product discovery process?
In order to answer these questions, we must first talk about the different types of IT architecture, conventionally divided into three types:
Enterprise architecture
Solution architecture
Technical architecture
Enterprise architects deal with the implementation and structuring of IT projects to achieve business goals on a strategic, enterprise level.
Technical architects, on the other hand, deal exclusively with the solving of engineering problems and structuring of projects.
Solution architects act as a bridge between technical and enterprise architectures – in simple terms, a solution architect’s job is to find and implement the best technical solutions to solve business challenges and problems.
In product discovery, a solution architect will be your go-to person for any technical questions you might have and will ensure your product is technically feasible.
Software product architecture layers
Naturally, they collaborate intensely with the other members of your product team.
For example, they’ll collaborate with the UX/UI designer to make sure their designs are technically feasible which’ll save you both time and money.
As a senior engineer, they have the expertise to ensure that the technical foundations of your product are rock solid, making life much easier for engineers down the line when they’re developing your product.
What does a solution architect do during product discovery?
Now that we’ve covered what a solution architect is and their importance to product discovery, let’s cover some of their main responsibilities during the discovery process.
Their key tasks during the discovery process are:
Defining and framing the product and its features
Determining the technical feasibility of the product idea
Deciding on the tech stack to use
Identifying and mitigating technical risks
Estimating the budget for the product’s development
Now let’s cover each of these tasks in more detail.
Defines and frames the product and its features
Every product starts its journey as an idea.
Validating your idea is a key step in the product discovery process. Our solution architect will be in touch with you from the very beginning of the discovery process to maximize the odds of successful validation of your idea.
They’ll help you define, frame, and refine your product idea and its features.
On the first call with you, they’ll find out essential information that’ll inform their work going forward, such as:
What your idea is about
Which features you consider essential
Will it be a web or mobile app or both
Will it include messaging or not
Will it include in-app payments
They will then go to work on coming up with a sketch of the basic features, user paths and user flows.
App flow
At this stage, we’re far from the final look of your product, this is simply laying the foundation for development further down the line.
In preparation for the second call with you, they’ll prep questions about any uncertainties they might have and come up with ideas for new features.
The goal at this stage is to find out as much information as possible about your idea – this will not only make their other tasks easier but also help developers later on in the development process.
Determines the technical feasibility of the product idea
Determining if your idea is technically feasible is the most important task the solution architect has in the product discovery process.
Coming up with features and planning app flows is fruitless if the idea itself isn’t technically feasible.
Types of feasibility
Technical feasibility analysis is one of a number of feasibility analyses that are usually done when evaluating a product idea.
If your idea turns out to be technically unfeasible, you should go back to the drawing board and try out another idea.
So, how does the solution architect determine the feasibility of your idea?
The answer is robust research and their years of experience working as a software engineer.
The question they’ll ask to determine the feasibility of a particular feature in case your initial idea is unfeasible is “Is there another solution to this problem?”
If the answer is “no, there isn’t”, that means the idea is technically unfeasible.
In some cases, they’ll be able to tell if a particular feature is feasible or not right from the start.
In other cases, a feature might be technically feasible but too complex and expensive to develop compared to another solution.
Let’s say you want to add a messaging feature with user-to-user messaging available on your platform and you’d like to integrate Whatsapp due to its popularity and large user base in your location.
While the Whatsapp Business API can be integrated with your product and does offer plenty of features, it doesn’t support direct user-to-user messaging on other platforms i.e. outside of the Whatsapp app itself.
In that case, our solution architect will propose a different technical solution to enable you to have user-to-user messaging available in your product.
Decides on the tech stack to use
Choosing the right tech stack is absolutely critical to the success of your product’s development and the overall success of the product itself.
A tech stack is a collection of tools and technologies used to develop a software product such as:
Programming languages
Libraries and frameworks
Operating systems
Third-party tools
Database systems
Hardware architecture
All of these elements have to work in concert with one another for a software product to be functional and successful.
Tech stack & tech stack examples
Choosing the right tech stack, then, is one of the most important tasks our solution architect has in the product discovery process.
Just like no 2 products are exactly the same, tech stacks will also differ from one product to another.
A complex, cross-platform product will have a wildly different tech stack to a simple mobile app.
For example, depending on if you want an iOS or an Android app the tech stack will have different programming languages – Swift and Objective-C for iOS and Java and Kotlin for Android being the most popular.
On the other hand, if you want a cross-platform app, the tech stack will include Flutter as the main programming language.
Ultimately, the decision on which tools and technologies will be used in development comes down to:
Requirements identified during product discovery
Product platform
Scalability of the different tools and technologies
Availability of our developers
Our specific strengths and areas of expertise
The solution architect’s job is to consider and weigh all of these factors and decide on a tech stack that best fulfills all of these requirements.
Identifies and mitigates technical risks
Every product’s development cycle is littered with numerous types of risks that can have severe consequences for the success of your product.
Some risks like revolutionary breakthroughs that make your initial product idea obsolete or severe economic contractions that change your customers’ spending habits are out of your control.
Technical risks, however, can be minimized if you have the right development partner.
Every product comes with its own set of technical risks that are identified on a case-by-case basis.
Igor Caleta-Car, solution architect
Technical risks are those that impact the quality of your end product and they often stem from the following:
Constantly shifting requirements
The complexity of your product
Difficult module integration
Outdated tools
Poor code and support
If, say, a particular must-have feature risks the functionality of other features, they’ll propose an alternative solution that’ll preserve the other features’ functionality and security.
And in case there aren’t any satisfactory alternatives and the risk can’t be mitigated, they’ll propose axing and rethinking that particular feature.
The key question that’s answered in this process is “If we take this risk, what’s our reward?”
If the potential rewards of a particular feature don’t outweigh the risks, then it doesn’t make sense to risk the success of your product just to have that feature.
Any lingering technical risks that might remain after product discovery will be mitigated by our robust quality assurance (QA) protocols.
Estimates the budget for the product’s development
The final task our solution architect has during product discovery is estimating the budget necessary for your product’s development.
Not only is it the fairest compensation model as developers are paid exactly for the amount of work they do, it’s also flexible in case project requirements change.
So, let’s imagine you decide to remove some features during product development – with a time and material contract you’ll end up paying less while with a fixed-price model your costs will stay the same.
Pros and Cons
Pros
Easy project start
Fast response to market changes
Dynamic work scope
Practical testing of hypotheses
Product quality
Transparency
Easier to prioritize
Cons
Low budgeting control
Uncertain deadlines
Deep involvement from the client
Of course, the inverse is true, too – adding requirements to a project will increase costs but the flexibility and transparency provided by using this model are worth it.
Estimating the budget begins by writing out all the features and tasks needed to develop them.
Then, depending on the project’s scope, the solution architect will determine the number of developers needed to complete the project.
From this, they can estimate the time that’ll be needed to develop the minimum viable product (MVP).
Naturally, a simple Android app, for example, will be significantly cheaper than a complex, cross-platform app.
Also, the price will increase if you’re looking to develop your product further than just an MVP.
Once they’ve analyzed all of these elements, they’ll give you an estimate and calculate the monthly budget necessary to successfully develop your product.
Solution architect in product discovery: summary
A solution architect is one of the key roles we employ during our product discovery process.
So, what does a solution architect do during product discovery?
To summarize, their main tasks are:
Defining and framing the product and its features
Determining the technical feasibility of the product idea
Deciding on the tech stack to use
Identifying and mitigating technical risks
Estimating the budget for the product’s development
If you’d like to learn more about our product discovery process, feel free to contact us or read our other articles on the topic.
Nino is truly passionate about what he does. A lifelong software development enthusiast, he started his journey by building a simple ERP for his dad’s business back in high school. With 20+ years of experience in software architecture, he’s one of the best in the business when it comes to translating business requirements into feasible software solutions.
When he’s not designing top-notch architectures for every type of project imaginable, you’ll find Nino building wooden ship models and competing for the title of best table tennis player at DECODE. His ideal workspace? A pine-tree shaded terrace with a view of the sea. Doesn't get much better than that, right?
