And if there is one thing that I have learned, even in my short career as a designer, it’s that there are as many answers to that question as there are dusty bottoms of backlogs out there.
Therefore, I’m not presenting or proclaiming to have yet another right answer on how to build the right product right. But what I do have, are some positive, and hopefully useful, experiences that I have made with different teams in different companies which helped us to define and agree upon these myth-enshrouded next steps. I will outline a set-up and constellation within product development teams, which allowed us to progress at a steady pace, aligning involved parties and create value without much frustrations or the feeling of neglect.
Figure 3
Three is an omnipresent number. As humans, we encounter it in all the different parts of our lives. From religion to image composition, from spirituality to legislation, from geometry to astronomy. Three is ubiquitous.
In Christianity, there is the concept of Trinity, the unity of father, son and holy ghost. They are described as distinct, but inseparable. It depicts a core belief in this religious orientation. In the field of writing there is the “Rule of Three,” which states that events, depictions or descriptions of traits are more satisfying and easier to remember if they are listed as groups of three.
And three will also play a role in our little story.
Minimal steps forward
In the world of Agile development, the concepts of MVP, MLP, MVC and others, are thrown around and heavily used. And albeit each concept is bearing its own nuances, definitions and emphases, they are all describing a similar idea. I’m aware that I put myself at risk of opening up Pandora’s box, but I dare to say that the fundamental concepts of all these principles share a common objective: Supporting product development teams on their quest to figure out what should be their next step to help their users.
The intellectual mothers and fathers behind these concepts are providing some more guidance on what’s important and what to consider during this process. There is a myriad of thought leadership pieces on this topic available. The mantra of desirability, feasibility and viability has been established by IDEO. Marty Cagan describes in his famous book “Inspired” a triumvirate of “valuable, usable and feasible.” And Martin Eriksson describes it with the role of product management as being “the intersection between business, technology and user experience”.
All of these definitions and attempted explanations describe a similar line of thought. To move a product development process forward, you need to take into account these three perspectives. I’m deliberately not saying “creating a product or service” since exactly not doing so can also be an option.
As a preface, I’m describing my experiences from a cross-functional teams point of view. This means, a development team is a self-contained, independent entity, which consists of developers, designers, potentially quality assurance engineers, a product manager or owner and depending on the methodology, some kind of project manager (e.g. Agile Coach, Scrum Master, you name it…). In addition, there are also connections to other parts of the organization, e.g. the marketing department, the sales team or other involved parties. They do not belong directly to the development team but do have some impact or stake on the progression of a project.
The decision-driving troika
N.B. I don’t want to introduce a new term here, the abbreviation DDT is just used in this article to convey the concept.
Coming back the ominous figure three, to make the best product decisions, I have made the best experience with establishing a decision-driving troika (DDT) of product, user experience and engineering. Over the course of various projects, multiple companies and a variety of involved people, I have seen the best outcomes when these three disciplines work together like a well-oiled machine. Having these three roles work together, which will — without any question — turn into a collaboration of harmony and friction, you will be able to truly create valuable, feasible and desirable solutions. I would even argue that this triangle should be seen as the incarnated product management.
There are many good resources out there which describe and define the different roles and responsibilities involved, therefore I will only explain them briefly here. João Craveiro provides an interesting view on how these professions, roles and remits overlap, by analyzing and comparing the two concepts from Marty Cagan and Martin Eriksson, described above.
Product Managers/ Product Owners
Product Managers are often associated with the business side of things, the “valuable” part of the equation. But this would be too short-sighted since a product person does a lot more than just arguing in the name of business and profit. To impersonate the product perspective, the person needs to be aware of more than just monetary or growth concerns. She needs to be able to locate the feature, product or service within the bigger vision of the company. She needs to have an understanding of what is needed to address a prevalent need.
Engineers
Engineers are usually covering the technical side when it comes to software development, because… well, they are the experts. But this doesn’t mean they should only get involved when the implementation is the order of the day. Incorporating technical understanding from the beginning, and at all stages, and not only gathering technical input later, is a crucial point of success.Involving engineers as early as possible will save you from building castles in the sky. Technological possibilities and constraints will shape the scope and vision of a project and therefore they need to be considered right from the start.
Designers
User Experience Designers (or Product Designers, Interactive Designers, or whatever term might be en-vogue at the moment), are usually concerned about the “look & feel” of a product or service. And this is by no means limited to visual appearance but is rather touching on information architecture, logical structure and interaction sequences and much more the same way. I’ve already mourned over the misconception of the term “Designer” in earlier writings, but the bottom line is, “to design something” doesn’t mean to pretty-up an already existing concept or product, but rather shaping it from the spark of the idea, equal to a product person or an engineer. The strength of a designer is not being creative per se, but rather enrich the exploration and inspire others to allow them to drive.
Synergies
Only when these three roles comprehend each other as equal parts of the process, real progress can be made. They are acting as idea providers and enablers but also as correctives and gatekeepers for their team and the project. If there is mutual trust, interest and respect in each other they will be able to make sure that all voices are heard and all perspectives are considered to progress at a steady and sustainable pace.
Practical application
So far, so good, right? Until this point, I probably haven’t told you much new. This constellation has been around, in one form or the other, for years. But what does this actually mean in practice?
A product development process consists of different phases, and it’s sometimes divided into separate tracks, e.g. dual-track agile. A project usually starts with some kind of idea or request, which can come from a technology push, a market pull, client or internal feedback or really any other imaginable spark that forms the idea.
Ideally, an idea goes first through some kind of rough sanity check, where the DDT acts as a gatekeeper of the product development team. They need to assess if an idea is worth moving forward. One way to do this is by translating the idea into a rough “product requirement document.”
Probe the idea
Despite the daunting title, you shouldn’t become discouraged. It doesn’t have to be an overwhelming and time-consuming task. What it does though, is forcing the three roles to delve into an idea, together, for the first time. They will need to describe an idea in a bit more than just a couple of words. They will need to answer questions around why to build something and who would be the user or beneficiary.
This shouldn’t be too detailed, or accurate and it is by no means binding. But if there are already problems answering these questions, it’s quite likely that the idea might not contain the value or impact for your users as it was initially intended.
This step can also be considered as “framing,” since it already helps to scope a project for the first time. And because the framing is made by the three desired intertwining properties — viability, feasibility and desirability, you remember? — the scope of the project is realistic and appropriate.
One additional benefit this type of pre-check entails is an implicit list of extended roles and departments which voices should be heard during the development process. This includes, for example, the marketing team, which needs to work out the messaging around a new product and plan an announcement ahead. This should also happen in collaboration with the development team. My former colleague, James Stanier, recently wrote an excellent article about product releases and how to plan them, from an engineering side as well as considering marketing undertakings.
Understanding
Once an idea has passed this first hurdle, the team moves on to the next phase, which is usually labelled as something like “Understanding,” “Empathise,” or “Research,” again depending on which school of thought you follow. The goal of this phase is to learn and understand the situations your users are in, which challenges they face and which problems they have.
This -usually- (read: hopefully) happens via different types of user research, from qualitative user interviews over quantitative data evaluation to third-party desk research and other methods. Unfortunately, this is also the phase which is most likely to be dropped due to time and resource constraints. Again, there is a myriad of brilliant sources about why user research is essential, how you can incorporate “Lean UX Research” into your organization and how to make sure your colleagues understand the value of it.
And let’s face it: I’m not the one who is allowed to cast stones. But ideally, you want your team, or at least your DDT, having user research internalized as second nature. Hearing someone from your team saying “We shouldn’t think about solutions before we haven’t fully grasped the users’ situation” could be seen as a designer’s wet dream.
Again, having the product person, the engineering side and the designer work collaboratively on identifying these user problems will nothing but help to advance the project further. It’s one thing to have a 20 page UX Research Report, which lists potential issues, but likely no one is going to read it. But it’s a completely different world if you watch a user performing a tedious and cumbersome task first hand. Even just watching a recording of a user test will let everyone experience the unease and help them empathize.
Further development
This empathy will then be invaluable during the “ideation” or “idea generation” phase. It will help to focus the discussion around the actual user problem from all three perspectives — product, engineering and design, you guessed it? And the same is true for all following phases and cycles of the product development process, i.e. prototyping, testing and iterating over the concept.
There are people who may argue that having a “three-headed creature” as the “decision maker” will let the decision process become slow and risk a “design by committee” anti-pattern. But I actually have made the opposite experience. If your product, engineering and design troika is aligned from the beginning, share the same understanding of a project goal and act in concert, this was way more efficient than having a single-decision authority, which needs to push things through even against consent or valid argumentation.
Having these three roles discuss, decide and commit on approaches and scope of a product or service will ultimately also result in solid reasoning why or why not things will be handled. There is an implicit output of reasons and motivations around every decision which will help in discussions with the team, the stakeholders or other sources.
Involve these three parties will equip you with the necessary armamentarium to self-validate, assess and adjust your project along its way. Considering the three different aspects of a product will further help you to keep the balance between small improvements and bigger bets. It will support you in working towards the company vision and create something which is truly valuable, viable and desirable.