Who makes the Product & Technology Consulting team?

The Product & Technology Consulting team consists of Solutions Architects and Product Solutions Architects. 

Solutions Architects

Solutions Architects bridge the gap between business problems and technology solutions by:

                         
  • selecting the right architecture and technical stack for each project;
    •                      
  • validating the feasibility and cost of proposed features;
    •                      
  • helping the clients devise more cost-effective alternatives to their ideas;
    •                      
  • making sure that the new solution fits within the existing enterprise architecture.
    •                      

We’re responsible for creating a comprehensive architecture for a technical solution, creating frameworks for collaboration between the software provider and the clients, and offer strategic guidance throughout the entire development process.

Product Solutions Architects

The task of Product Solutions Architects is to understand the clients’ challenges and business goals, and provide ways to help them avoid the pitfalls of the early stages of product development. With product management and startup experience, they are also well equipped to lead discovery workshops.

How does the Product & Technology Consulting team work?

From the combined powers of solution architects and product solution consultants comes Captain Overall Understanding and Design! 

All jokes aside, though, that's more or less how it works. We use our different backgrounds to fuel each other's creativity and propose solutions that best match the clients’ needs and fit within their budget. 

The goals of the Product & Technology Consulting team can be summed up as follows:

                         
  • Help the client understand and communicate their own idea as effectively as possible;
    •                      
  • Identify blind spots in the project;
    •                      
  • Make sure everyone is on the same page so that development can kick off efficiently.
    •                    

Actions outlined in these points also include aspects such as scoping, estimating, designing the architecture, selecting technologies, to name a few. 

Where the department is located within the whole process of product development, however, is well defined by a quote I keep going back to in my talks and writing. It's by

Hollis "Andy" Kinslow, an engineer who worked on the IBM SSEC and TSS/360, and I believe it captures the essence of incremental development. Since Kinslow said this at the 1968 NATO Software Engineering Conference, it was certainly ahead of its time in many ways. 

“The design process is an iterative one. (...) In my terms design consists of:

                         
  1. Flowchart until you think you understand the problem.
    2.                      
  2. Write code until you realize that you don’t.
    3.                      
  3. Go back and re-do the flowchart.
    4.                      
  4. Write some more code and iterate to what you feel is the correct solution.”
    5.                    

The Product & Technology Consulting team is the first stage of the first phase of the above cycle. We don't try to "waterfall" the process; instead, we help the client to get to an internally consistent story, on top of which we build a sketch of the architecture and just enough up-front design. Then, we share and refine that understanding with the development team so they can move into the second point and iterate from there while cooperating with the client. 

Now, depending on your background, you may find the phrasing here archaic—especially the "flowchart" bit—but the process is actually surprisingly modern and agile. We do use the modern art of Story Mapping and Event Storming (with real users, whenever possible), as well as the ancient alchemy of UML (and its more contemporary counterpart, the C4 Model). 

In essence, we use numerous tools to make sure we iron out any outstanding inconsistencies and frictions in the modeled process, as well as build a common understanding and language to use within the domain. That’s our job, in a nutshell.

We believe that thorough understanding and modeling of the domain have to play a leading role. The technologies used are simply implementation details: they come secondary since they're easily swappable. 

That said, as a company, we have lots of experience with various frameworks, libraries, and SaaS platforms. The Product & Technology Consulting team uses them to recommend good starting points so that we don’t have to reinvent the wheel. 

What do you need to succeed in the Product & Technology Consulting team?

Firstly, you need a lot of experience to succeed in this role. Personally, I find knowledge of domain modeling and architecture design more important than a vast toolbox of specific technologies. 

Why? Simply because we're aiming for long-term relationships with our clients, so we need to be building software which remains “soft”. By this, I mean the software should be easy to modify in response to changing business needs, in every possible sense of this term.

Working in the Product & Technology Consulting team also requires a specific kind of personality. And I don't mean this in an elitist way: it's just different from a programmer’s work. It's far less structured, and much more chaotic. If you frown at meetings, let alone the ones that pop up with a maximum of one or two days’ notice, it's definitely not a job for you. However, if you're excited at the prospect of becoming at least fluent in three different industries over the course of a month, and remaining so for another two or three months, then the Product & Technology Consulting team might be just what you need in your life.

Your level of English is also very important. Sifting through piles of documents and talking with clients from all over the world will push your communications skills in general, and English skills in particular, to the absolute limit.

Final thoughts

I often joke that when I joined STX Next, after many years in product companies, one of my goals was to switch projects more often. So, it's only natural that I eventually landed a position where I switch them multiple times a day. This is certainly not everyone's cup of tea, but if you look at programming through the lens of Domain-driven design, and you’re interested in helping clients get the most out of their ideas, it may well be yours.

On the other hand, if you’re looking to build a new product and need some expert help, myself and my colleagues at the Product & Technology Consulting team would be more than happy to assist you. You can drop us a message and we’ll get right back to you. 

In the meantime, if you’d like to read more about software product development, take a look at the articles below. They’re packed with useful insights and practical advice: