Business Design Architect: don’t digitalize without one.

Find out who they are and how they assure project feasibility and success.

Sclable generates value for our clients (and their customers) with design, data and code. To bridge the gap, clients need a combination of software development experience and business acumen. Pulling it off is complex and relationship-driven, and Business Design Architects are more than up to the task.

Here, Jan Hilmar answers clients’ most frequently asked questions about why the role is essential to successful digitalization.

What’s a Business Design Architect?

In short, a Business Design Architect like me ensures successful digitalization by leading a project through its entire lifecycle. From strategy to scale.

We decided not to use existing names such as “Product Manager” or “Product Owner”, as the role is more than that. A Business Design Architect is the missing link between the dev team and the client, streamlining communication and acting as a translator between the two.

What does a Business Design Architect do?

I translate a clients’ business needs into a concept that fulfills the three pillars of product development: desirability (fulfills high usability standards), feasibility (exists within technological limits) and viability (brings business value).

To do this,I get involved in a project from the beginning, and take care of pulling in the right experts into each project at the right time. It ensures that data, design and code are optimized.

In these early stages I start creating agreements on product features and project scope, as well as conducting research and running client workshops. I also spend a lot of time in meetings and in front of whiteboards drawing up concepts and visualizing potential solutions with the UX Architect.

I’m also responsible for formulating User Stories. This includes reviewing the client’s currently accepted user journeys and doing Q&A sessions with their experts to get missing information.

Working between the client and developers, I bring their perspectives to one another. For example, I’ll present User Stories at Agile Ceremonies because they answer questions for the development team that come up during backlog refinement. I use Spring Reviews and Standups to deliver feedback to the developers, removing roadblocks so they can work without impediment.

I help clients come up with new features in-line with their goals and I’ll gatekeep those that aren’t.

Finally, I ensure everything is delivered!

How do you create value for the client?

At Sclable, the aim is always to work at “eye level” with the client, because understanding them deeply is the only way to truly improve their business.

That’s my task.

I begin by analyzing the client’s business and market. I might even do this before meeting them the first time! Then, I’ll lead workshops where I apply Design Thinking tools to the clients’ key processes. This helps the development team fully-comprehend the unique challenges and opportunities. Only with this newfound information can I initiate the next step: offer potential solutions on UX, business and technological levels.

It’s vital I get started immediately, because the team needs to learn about new subjects quickly. Sclable’s a consultancy after all. To bring real value, we need to be a step ahead.

What’s the relationship like between a Business Design Architect and the client?

It’s all collaboration, so how a client handles it depends on how they work. In some cases, they’re used to an agile mindset and embrace our way of working. They’ll happily commit to things like pulling key players from the company out of daily business to work with us. On the other hand, some are unfamiliar, so my job also entails onboarding these clients into Sclable’s way of working. I explain why we want to talk to the experts, see their factories and offices, and bring leaders into workshops.

Luckily most clients understand why doing things Sclable’s way produces better results.

How do you accommodate a client that isn’t into such intense collaboration?

In the (very rare) case where a client insists on classic software development (with fixed requirements formulated by the business without talking to the experts) I’ll flag it, because we’re probably not the right partner for them.

What makes for a productive Product Owner and Business Design Architect relationship?

For Sclable, the client Product Owner is the most central role because they’re our first point of contact to the company. A productive relationship requires regular alignments, presence in all workshops and keeping the big picture in mind.

It’s also important you have the right person for the job. They should be decisive, will have worked in an agile(ish) environment and know that software development is iterative. They also need to be well-connected in their company and know who to contact to get info, make decisions and do approvals.

It pays off to do an onboarding workshop at the start. The Product Owner can tell me about their company and provide a deep look into their world and the challenges the business faces. I introduce them to Sclable’s way of working, outlining the product development process, the basics of a lean start-up and agile software development.

Finally, what are the three main ways clients benefit from a Business Design Architect?

Improved communication: I manage it between the Client’s Product Owner and Sclable’s dev team. Saving clients time and effort.

Providing structure: I translate the client’s business needs into technical requirements (and vice versa), improving final output.

Working at eye level: To deliver results that solve deep-seated challenges, I quickly learn the ins and outs of a client’s business (sometimes deeper than they do).

This article was written for Sclable’s blog on Medium. Follow us on LinkedIn to get notified of new posts or check out our website to see the work we do!

If you liked it, give it a 👏 and share if you ❤️.