Key product discovery roles: Solution architect

A well-executed product discovery process will form the foundation of your product’s further development.

At its core, product discovery is an intensely collaborative process.

This is exactly why it’s necessary to assemble the right team to carry out your discovery process.

We’ve already spoken about the 4 key roles in product discovery we employ here at DECODE.

Here, we’ll examine the role of the solution architect in greater detail.

Let’s dive in! 

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.

Learn more about our discovery process →

App development starts with product discovery…

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.

At DECODE, we’re firm believers in the time and material contract model.

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

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.