Having some years of experience working with product teams, I’m pretty sure that this multidisciplinary and agile approach is the right one for developing innovative and customer-centric solutions that really make users’ lives easier. However, product development is not about the sum of each individual’s work, but it is all about how those people can work together in a sense of collective work. In that regard, gathering individuals with so different backgrounds (as it is supposed to be in product teams) to work like that might represent a big challenge. We as humans tend to work inside our comfort zone, so it is likely that throughout team’s sprints, developers start coding features which were written in the format of user stories by the Business Analyst and have been previously pointed as hypothesis by the Product Owner through customer research and stakeholder validation. It makes it difficult to know what the team as a whole is doing and have a sense of collective progress, paramount for agile product development. Furthermore, the key point here is that this working flow does not seem much like agile, doesn’t it?

I want to address such topics here and show how product roadmaps can help the team collaboratively gather the pieces of work and have a view of long term desired outcomes that afterwards are going to be broken down into sprints, not the other way round.

Here are five reasons why product roadmaps can help your team’s progress

1. Having long term plans help you make adjustments along the way

Have you ever thought that having no long term plans is just like piloting an airplane without instruments? Just like airplane instruments, a good roadmap must tell you if you’ve already reached cruise altitude or if you still need to boost your product’s engagement, for example. To do so, you should compare your current metrics with the ones you’ve previously defined with your team when building the roadmap. Looking at this, your team can refine the features, sprint’s goals, make decisions based on data or, at least, realize sometime in advance that some desired outcome is not going to be achieved, enabling you to activate your plan B. Otherwise your team is just working sprint after sprint with no acknowledgment about the impact of its work on the business.

Successful sprints don’t mean successful products

2. It connects the pieces of work into something bigger

Even though each one’s work is important and meaningful, it is much more motivating to know what your team is going to deliver as a whole. This is where the real meaning of work takes place, instead of just delivering tasks that were assigned to you through your team’s board. The roadmap should be accessible and visible on a daily basis, so everyone can take a look at it everyday and feel the importance of their hard work.

Also, it is paramount to know that features and deliverables are related to a bigger product and company vision. Giving people a desired condition instead of a desired path creates a favorable environment for creativity, innovation and collaboration.

3. Helps setting and clarifying priorities

One of the most important skills for a product team (especially for the Product Manager) is the ability of saying no! Users are going to make requests, stakeholders are going to have opinions and even the CEO of the company may issue some special feature requests, but if you try to satisfy everybody, eventually you won’t do any good for anyone! If your vision where to go is clear, that will make easier for you to refuse requests that are not related to it.

Another point is that the amount of options and paths available to us are almost infinite nowadays, so we tend to question ourselves more than we should about the path we are following and step back when the best thing is to move forward and iterate on results.

Reinforcing this point, some time ago I came across the concept called the Fear of Better Options (FOBO), that explains why we tend to work in such way.

4. It motivates the team to move on to the next step

When you are delivering a feature it is possible that you are facing many technical issues and things do not work as expected. So, if you don’t have a clear vision about what comes next and why it is important, your motivation to work harder to overcome such challenges decreases. Remembering everyday that time is a resource that runs in shortage increases our critical view about problems and why to solve them.

5. It gives visibility to your stakeholders

Have you ever thought about how many meetings you could have avoided if there was a roadmap? As we are working in an agile environment, we are not supposed to give status report to stakeholders, but at the same time I assume your team does not work in a bubble and your product must be part of a bigger company strategy. In that sense, it is essential that your goals are accessible to everyone in your organization as well as your progress towards it. This kind of transparency increases the buy-in you have from senior management even when things don’t go as expected, because the whole strategy that relies on your product can also be adjusted if it is needed. Moreover, it creates a sense of collaboration with everyone involved.

Tips for building your team’s roadmap

1. Don’t “validate” the roadmap with your team

The tricky thing here is the word validate. One of the main good things about having a roadmap is the chance for collaboration that this exercise brings. However, there are some Product Managers that believe they own the requirements as well as the outcomes and the team needs just to validade the technical feasibility and the desired deadlines, but an exercise like this does not generate engagement and sense of ownership within team members. The role of a Product Manager is actually a facilitator of the whole process, someone who gives direction and understands a broader context of the company, giving the team a vision of why things should be done. This description of role is also related to the concept of product leadership, as you can see in more detail here.

There are many collaborative techniques to build a roadmap and I’m going to list a few:

The Radical Product prioritization — It is an exercise to relate features and potential outcomes to your product’s vision;

The Go Product Roadmap by Roman Pichler — Doing this exercise, you and your team are going to list expected delivery dates, goals of each deliverable and metrics that are going to be used later on;

The Lean Inception by Paulo Caroli — It is a five day exercise that is going to thoroughly make you and your team think about many aspects of the product, ending up with a MVP Canvas;

2. Leave room for unforeseeable work

The need to fix bugs bugs, receiving requests from Customer Experience, stakeholders and unexpected technical debt is something unavoidable. One good thing to do is understand that you are going to compromise along the way in order to meet those unforeseeable needs and don’t get frustrated about it. It is even better if your roadmap is not so tight regarding your capacity and you can accommodate such pieces of work that will come at some time and still meet your planned deadlines.

Some agile best practices state that you must leave 20% of your sprint capacity to unforeseen work

3. The roadmap must not be a list of features

It is very common that teams just add a list of features in a presentation and call it roadmap. The real thing is that a roadmap must be a conversation with everyone interested in that process, from the team to stakeholders. In order to be a real conversation, it also needs to state about the business outcomes that are expected from the product. It is even better when the team can relate its goals with strategic initiatives of the company, so even the senior management can connect team work with high level goals.

The Go Product Roadmap shown above is a good example about how to input business information on a roadmap.

4. Validate your roadmap with data

No matter how hard you and your team have worked on building the roadmap, things are going to change along the way and so is the roadmap. Whenever you do this exercise, bear in mind that things are not set on stone. Other opportunities might appear and you need to grab them, changing what has been previously planned. As a result of your team’s deliveries, pick up the data available and cross check them with the metrics you’ve defined and, when things don’t go as expected, don’t be afraid to pivotate and try new hypothesis. If your first delivery didn’t achieve the expected outcome, it may be better iterating over it instead of just moving to the next one on your roadmap. It is virtually impossible to know in advance how the market is going to react to a new product or service, but data will be your best friend in order to try to figure it out.

Besides the metrics that are on your roadmap, the Google HEART Framework is another great tool to think about the metrics related to your product.

Traps that are easy to fall into

Even if you do encourage your team to follow this process, do things collaboratively, validade deliveries with good data, think strategically and communicate well with your stakeholders, there will be many traps on your way and you’d be better be aware of them. I’m going to write down some that I’ve already faced myself:

Don’t stick to your roadmap, change it and (over)communicate!

As I said before, your roadmap is not set on stone. Don’t get too attached to the first version of it and be aware that it is going to change. It is important, though, that whenever something changes, be sure that your team equally shares ownership of such changes and your key stakeholders are up to date. Communicating with stakeholders is a huge amount of the Product Manager’s role, so share your ideas with them, ask for help whenever needed, explain why you think things need to change and it is your job to make sure they have a complete understanding about the situation, not theirs.

Think carefully about the reasons why some expectation was not achieved

When we don’t achieve a certain goal it is easy to think that the team’s pace was not fast enough to deliver on time or the real product is not as good as the prototypes were. But in real life, reasons for failure go far beyond that. Market research may have come with conclusion that does not reflect customers’ needs, users may be facing usability issues that nobody has noticed and many other things may be the root cause for unmet goals. In a situation like these, gather your team, be humble and listen to everyone’s opinion, it is very likely you are going to learn and decide a way to move forward.

Your product roadmap is not your company’s strategy

When talking to senior management, it is common that these people put too much expectation over your product, trying to achieve a wide range of goals with a single product. Such goals might be even contradictory and spoil product market fit. Don’t be afraid to tell anyone in the organization about what your product does not do and is not related to its vision (that’s why it is so important to have it clear), so you can even suggest creation of new products if the company has other needs to be met. Candid conversations will be your best tool.

Be aware that your roadmap will be connected to one (or maybe a little bit more) strategic initiatives of your company, but if you try to fulfill them with a single roadmap, chances for you to get lost are high.

Roadmaps are not status report

Roadmaps will never tell sprint’s progress and they are not even supposed to do so. If anyone looking to a roadmap tries to grab pieces of information like these and complains to you, it is his/her mindset that is wrong rather than your roadmap.

If you face a situation like this, try to explain the purpose of this material and step up the level of the conversation to the business outcomes you and your team are seeking.

Don’t forget your roadmap!

Well, so you and your team have spent a lot of time building the roadmap, goals are aligned, everyone is held accountable and motivated to achieve them. That’s great! So after the collaborative sessions of roadmap building, the Product Manager saves it in his/her computer, the team starts working on the features and that’s it, right? NO, absolutely no! It seems obvious, but if we don’t see the roadmap and talk about it on a daily basis, we are going to forget all the precious and hard work we have done to build it, or worse, we will forget about what we are committed to do as a whole and start working as a group of individuals on their on, which is exactly the opposite of how a product team should look.

Whenever you think some of those traps is happening, give a step back and think what you can do to avoid it. Use the tools available to you and change the course of things.

Liked what you’ve just read? Don’t forget to give this story a round of applause :)

Why product roadmaps are so important was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

A lot has been talked lately about how technological innovation is reshaping our world. Technology’s rate of improvement is increasing in a fast pace and advancements are being made in a variety of fields that, combined, shift the way we do business, run our companies and even relate to one another. But how can you really grasp what it means and take advantage of it? I’ve been studying this subject and would like to share here my thoughts about it.

When it comes to the technologies that are reshaping our world, the Fourth Industrial Revolution is a rich source of information that is worth taking a look

First of all, let’s have a common understanding of technology

Even though it seems pointless to conceptualize technology, the absence of common ground for this word is the beginning of misunderstanding when we talk about technological innovation and I’m going to specify it.

One definition of technology that I really like is the one that was drawn by Lewis Mumford in his book “Technics and Civilization”, 1934; Which is: Technology is something that transforms raw materials (geological, biological) in some useful way.

Notice that this definition is broad and very inclusive, though. From that perspective, anything from hardware, software, processes, skills and knowledge can be seen as technology. Building on that definition, I bring the example of a Laptop; It is technology, regarding the concept we’ve just seen, but it can also be a combination of a wide range of technologies, it all depends on how you analyze it. And that’s one thing that can lead us to misunderstanding. Another one is related to how perceivable the technology adopted to develop some product is to the end customer. Touch screen, for instance, is a technology that was a breakthrough for the smartphone industry and jumps into the customer’s face in the experience of use of a smartphone. Wearables are other good example for that. On the other hand, think software programming languages: They are also technology and are used for developing mobile apps, which are paramount for making our lives easier nowadays, but we as users don’t have even a glance of what is running on the background. What really matters is what the product can do for us.

What about technological innovation?

The author Brian Author defines technological innovation in his book “The Nature of Technology”, 2009, as the improvement to existing technologies, the creation of new ones or the act of performing old functions with fundamentally new building blocks.

Connecting the dots here, both the Laptop and Touch screens were meant to perform old functions with new building blocks and enhanced performance. Software programming languages fit the definition of improvement to existing technologies, though.

Despite being fitted into different concepts of technological innovation, all those technologies mentioned above have their pace of improvement and there are some theories that try to understand and predict such rate. Moore’s law became widespread after Gordon Moore, in 1965, made his predictions about the improvement of computers’ processing power. However, there are a few others, such as Wright’s and Goddard’s law, being each one of those best suitable for different approaches of analyzing evolution (but this is topic for another post, as there are also room for disagreement about how well those laws perform on measuring innovation rate). Some metrics such as cost of investing in a technology or adoption within an industry can be used for measuring the rate of innovation. Metrics are important so that we have common ground to talk about what we consider as improvement. The key point here is to identify which kind of technology, regarding the definitions brought here, is going to be used by your business and which is the most important metric for you to make an investment decision. Also bear in mind that forces as design constraints, physical laws, human agencies and institutional factors drive the pace of innovation, being these last two most important for business. In the last few years, Moore’s law is being questioned as computer’s processors are reaching some physical limits, but this matter is not affecting customers directly, as the processing power we currently have available meets our needs. By contrast, human and institutional factors still prevent technologies like Blockchain to really gain widespread adoption into business use cases.

Some models try to explain these paces of improvement, analyzing the complexity of technologies and how invasive each technology is, but this is also subject to another post. You can also search for Mechanistic and Phenomenological models to better grasp this.

For businesses what really matters are innovation and business models, not technological innovation

We’ve been talking so far about technological innovation, but I would like to zoom out the subject and talk about innovation in general, which happens, in my perspective, when technology or technological innovation meets customers’ needs. Making a recap about the Touchscreen, it was a technological innovation that could be fitted into a business model and shifted an entire industry.

To counterpoint that, I want to talk about Netflix. The company is famous for its streaming technology that could make it present in everyone of us’ houses. What amazes me here is that Netflix was innovating much before that, though, when it changed the business model of movie rentals from a pay per use (with fines for late returns) to a monthly subscription with fixed price. I can’t help but wonder what would have happened to Netflix if the streaming technology had never been available, and if I can make my guess, I bet it would still be a successful product with possibly a really smaller scale. Streaming leveraged a new business model and gave to it a worldwide scale.

Both touch screens and Netflix are present in our day to day lives, but their birth came from two very different perspectives. Touch screen is a technology that can almost be seen as a product ready to be released to market, but streaming itself means nothing unless you have good content to spread around. Furthermore, the end customer has no idea about what happens in the background when he/she is watching a movie, regardless of what technological improvements are made. What they have in common is that it is paramount for any technology to become adopted to have a business model that can meet customers’ needs and turn it into a useful product.

There is an article published on the MIT Sloan Management Review called “Five Myths About Digital Transformation” that uses this business model concept using the example of Uber, that combined existing technologies to meet customers’ needs in a different way. There is also a very good post here in Medium called “We Need Breakthrough Business Models, Not Breakthrough Technology” that supports this idea.

To sum up, taking all these studies into consideration, I can say that technology really helps broadening the impact of businesses and providing gains of scale. It also can help you decrease the cost per unit service of your product, but the key point for successful products is still how well it can meet users’ needs and have a sustainable business model.

Liked what you’ve just read? Don’t forget to give this story a round of applause :)

What technological innovation really means for your product and company was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

The principle of modern product teams

Product teams are smalls groups of people who share the same goal of creating products for solving a set of users’ problems. They are formed by individuals with different skills, meaning that they should work collaboratively so they can gather team members’ skills and achieve results. Usually the scope of team’s work is broad due to the fact that it is linked to vision and strategy and not a fixed roadmap, it means that they are autonomous to choose what to do and it is expected that individuals can make decisions whenever it is needed as lots of questions arise during the work and also be accountable for those decisions. Consumers’ expectations change in a fast pace and product teams must be willing to meet them, assuming they will fail sometimes and changing their directions based on the results of their iterations.

There are some metrics that can be used for measuring iterations and frameworks for setting clear goals of vision and strategy. You can find references here and here

The reality of many companies

Hadn’t the environment of a product team been complex enough for itself, what happens is that many companies cannot rely on a single product team to build its products. There are lots of small product teams that, together, build one big product that is offered to the end user as a one single piece. Those teams have dependencies across them, they share accountability for what happens when all the pieces come together and thus one team’s work may have impact in all other teams across the company. This requires good skills at systems thinking to grasp all the impact of your work.

Spotify is a good example of how multiple teams work together do deliver one product

Why decision making is hard?

When we decide to do something, we are also deciding not to do something else as we have limited resources. Our energy is limited and so is our working hours, this means that every decision has its pros and cons, be it adding some feature to your roadmap or prioritising some activity because another team has asked you to do so. This process therefore involves risk taking, as we must assume that it is impossible to predict all the scenarios that may occur when making a decision. You can’t be 100% sure whether postponing some task will have an impact in the planning of other team or if delivering a new feature will rise issues and cause bad feedback. What happens is that many teams get stuck in this process, trying to analyse all the scenarios and find a perfect solution that involves no risk. As a basic approach for risk taking is that you must see the benefit that you can grasp if the risk doesn’t happen, but in the complex environment of distributed teams, it is much easier to see the downside of the risk instead of the possible benefits, considering that are many coworkers and consumers that can be impacted by your decisions. In the end, it makes it a real struggle to find willingness to move things forward.

I’ve recently read a post about the Fear of Better Options (FOBO), that explains many things that are in our mind while making decisions. Also related to this topic some researches came up with the Analysis Paralysis. Finally, if you want to understand better why we make decisions the way we make, it is worth taking a look at the human cognitive biases.

What can we do to overcome this slow process?

I think that there will always be room for improvement when it comes to decision making, so you can always do it in a faster pace than you are doing. I like to think of it as Lex Sisney defined in the book Organizational Physics. He represents success as the equation below:

In the denominator of the equation, Entropy is defined as the amount of energy a company spends doing the basics, the energy needed to survive. Integration, on the other hand, is the flow of energy the company can gather from the outside, be it money, sponsorship, new customers or a new contract. So, if a team spends a lot of time thinking about who it will impact when making a decision or who will be accountable by that call, the internal energy (entropy) needed will be very high and there will remain just a small amount of energy to think about the decision itself. In order to decrease this amount of energy spent in a complex environment, roles of individuals and teams must be very clear, so whenever a decision is needed, people know exactly to whom they must talk to get another point of view and move forward, as well as who holds the accountability for what happens later. By doing this, there will be more energy to spend making the decision itself, analysing options and choosing the best way forward, which is more likely to result in integration due to the results obtained.

It is also important that people within the organization notice that the energy that comes from the outside is the fuel for the company, so the internal process cannot be a block for moving your team forward and achieving results. This may make people more prone to take calculated risks when they see the potential outcome involved.

Liked what you’ve just read? Don’t forget to give this story a round of applause :)

Here is why you often feel product teams are slow at decision making was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

With the adoption of agile for many companies, product teams are taking place in a really fast pace, shifting the focus of deliverables from project budget and deadline to perceived value of the end user. Business units are not the only owner of the requirements anymore and a user centric approach is being taken by product teams chasing to meet user’s needs. In this landscape, both companies and teams are realising how crucial the role of the UX Designer is for achieving such goals, but one question still stands: Which is the best way to fit a UX process into the development cycle? Behind this question, also lies the doubt of whether UX Designers are part of product teams or should work in a different context.

Being part of a product team might be a game change for designers, who were used to delivering on demand projects hired by marketing agencies. Now, UX Design must support product strategy, which is therefore connected to the strategy of the company, rising the depth of connection between UX and the business. Engineers of the teams, on the other hand, must now embrace the uncertainty brought by the complexity of focusing on customer’s needs instead of a well defined list of requirements.

I’ve seen some different approaches of structure for UX teams that try to tackle all those challenges. In my experience, each one has its pros and cons and I want to share them with you in this post. But first of all, let’s remember some aspects of Agile Development and UX.

Agile Development

This picture above by Scrum Alliance shows the basics of the Scrum framework, which is one of the possible ways of agile development. As we can see, the backlog of the product is kept and refined until the sprint planning. In the sprint planning, the team is going to discuss the backlog and make a commitment of what is feasible in the next sprint iteration, so that this backlog becomes afterwards an increment of the product to be delivered. The team interacts on a daily basis throughout the sprint and can also change the priority of the backlog as feedback comes from the user or some unexpected difficulties are faced. The framework, by definition, is wide open and is up to you how to refine your backlog, define priorities, gather feedback from the user and do market research. This is when we start to make the connection between agile and UX, trying to find best practices for those activities, even thought there are no explicit mention to UX in the agile development process. Also, when we take a look at the usual roles of a Scrum team, there is no mention to the role of UX Designer, as shown in the picture below.

I am taking the scrum framework as an example, but whether you use Kanban, XP or other Agile approach, there is no specific process or role for UX.

The concept of UX

As user centred development and Agile are being adopted by companies, one thing that is being wider understood is that UX Design is not just Design. UX plays an essential role helping to define the strategy of user centred products, understand the needs of the target audience and finding the problems that need to be solved. Having those problems in hand, it is up to the business to answer if them are worth solving or not, if they are connected to the strategy of the company and if they can make a profitable product. Design is indeed part of the UX process, but it is much more related to execution than to research. This picture below highlights all the disciplines involved in the UX process.

Furthermore, with the rise of Design Thinking techniques, individuals across teams are tackling problems with another look, trying to redefine them and deeply understand what lies behind user’s needs. More recently, Google Ventures came up with the Design Sprint, which is another method to narrow problems and find the best solution. Both techniques are meant to be collaborative, and change the role of the UX Designer from the owner of the experience to the facilitator of a team process. But once again, there is no established process to fit this discovery frameworks into agile development.

References for Design Thinking and Design Sprint, respectively

So, how can we make the UX process fit into product development?

Also striving to find an answer, I went through research and found the book Lean UX. This book provides insightful approaches and examples on how a UX Designer can work inside of a product team. It makes the role of the design facilitator very clear and overcomes the old way of seeing a designer as the only responsible for the experience.

But when it comes to the reality of our teams, what I have seen are basically two different ways of UX professionals interacting with development teams: 1) UX people working inside product teams; 2) UX people working in a separate team, prioritising its design backlog and deliverables for product teams. I have also experienced the pros and cons of each one and I’m going to go through them:

1) UX people working inside product teams

Pros:

When UX people work inside product teams, the interaction with the Product Manager, who is the person in charge of prioritising and refining the backlog, tends to have less misalignment. As all individuals are close to each other, the designer can understand how the product team is going to compose the backlog in order to reach the aspired design. This means that the product may have intermediate deliverables before reaching a desired state, and this impacts the work of everyone involved. The iterations of the whole team are faster, as the team itself has the autonomy and skills to an end to end process, from design to the delivery.

Cons:

A common trap in this approach is that the UX Designer can turn into a person that only delivers what the team asks for, not what the team really needs. As we could see previously in this post, the role of UX Designer goes far beyond delivering screens, there is a lot of work to be done related to strategy and research. Being far from other designers can also cause a lack of improvement of the designer’s skills due to the lack of critiques. Furthermore, if you work in a Scaled Agile environment, there may be a lack of design patterns between teams that will damage the overall experience of the product.

2) UX people working in a separate team, prioritising its design backlog and deliverables for product teams

Pros:

When UX Designers work together, the design of the whole product tends to be well standardised even if the product relies on the work of lots of development teams. All the designs are carefully thought and aligned by the design team, at the same time that critiques happen. Moreover, the UX Strategy work is better distributed and gain importance, thanks to the deep understanding of UX Designers that their work is not limited to designing screens.

Cons:

Working outside a development team, it becomes pretty hard for UX Designers to be truly aware of the team’s timetable and schedules. This may cause delay on the expected design deliverables which are prerequisites for the development iteration. In addition, being far from the Product Manager often turns into a lack of understanding about the team’s needs and the design becomes to be seen as a roadblock instead of a leverage for the product. All those cons are harmful to the execution of the team’s iteration.

Now what should I do?

Well, I’m a big advocate that seamless execution can turn even the least novel ideas into something good. This belief is based in my experience with some product teams. As I was able to work with the two approaches listed above, the best results I’ve seen were achieved when the team has all the individuals needed for execution, including the UX Designer. Teams which are formated like this usually leave room for improvement regarding strategy, though, but good execution lessens this gap by the iteration over the product deliveries and the ability of gathering feedback. In contrast, I have already seen teams that got stuck into novel ideas of strategy but lack the ability of turning them into real life products and results are really bad. Not to mention that poor execution can take off the motivation of team members as they don’t see any progress in their work.

There are also two Medium posts that support this idea of good execution: Ideas are Great. Execution is the Best.; Innovation is Overrated: How Execution Can Make Up For an Average Idea.

Another interesting thing to point out is that your company’s format must reflect its strategy in order to make execution easier. So, unless if you are in the early days of your startup, probably you have already researched a problem that is worth solving and you now need to ship your product into the market to prove its market fit to start gathering feedback and revenues. Having this goal in mind, why would you have an independent UX cell?

The book Organizational Physics is a great reference to read more about Organizational design

With the evolution of Agile frameworks, there are also good practices that can address the cons of having UX people spread in product teams, such as guilds and chapters. Furthermore, the use of design libraries and style guides strengthens the necessary patterns for design.

Now I’m looking forward to know how you and your company are dealing with this subject! Write your thoughts in the comments below and let’s start the debate! If you liked this post, please do not forget to clap :)

Struggling to find the best format for your UX team? was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s been a while since I was first introduced to the Fourth Industrial Revolution and its concepts. It happened in late 2016 when I read Klaus Schwab’s book about the topic. At that time, the reading was kind of a mind-blowing one, making me reflect about many aspects regarding economy and society in the digital era. Since then, I have been also working with the development of digital products and, being pretty enthusiastic about both, I can’t help seeing a strong connection between them. We, as Product People, are fascinated by growth and the impact of our work. Revolution, by definition, means abrupt and radical change — but especially the Fourth Industrial Revolution is all about speed and breadth of impact, as you will see later in this post. This is just a quick and kind of obvious connection that can be made, so in this post I want to dig deeper into the Fourth Industrial Revolution and how the products we develop are strongly related to it.

The revolutions in our history

In order to talk about the Fourth Industrial Revolution, I will just briefly talk about the three previous ones. The First Industrial Revolution happened between 1760 and 1840, being marked by the construction of railroads, invention of steam engine and eventually making mechanical production possible. The Second Industrial revolution is possibly the most studied one, being lead by the advent of electricity and assembly line in the early 20th century, it was the time that mass production was made possible and virtually all industries we know used to work in this operation model until some years ago. The Third Industrial Revolution started in 1960 fostered by the development of computing, semiconductors and the Internet in the 1990s. All of those advents represent breakthroughs for humankind and therefore they have boosted the development of our society in their ages.

Until the invention of Internet in the 1990s, though, the lack of velocity and capability to spread worldwide were patterns for such revolutions. The previous revolutions were as well represented by one main event that changed the world. What happens is that the Fourth Industrial Revolution is an anti-pattern for its characteristics of depth and velocity of impact and is shaping the way we live in a much faster pace than ever.

The uniqueness of the Fourth Industrial Revolution

We currently live in an era in which internet is almost ubiquitous for all human beings, even though it was invented less than thirty years ago. Artificial Intelligence and Machine learning are subjects that had never been said until some years ago and now they are both must have capabilities for companies and professionals. The technologies brought by the Third Industrial Revolution are becoming integrated, sophisticated and powerful, creating global networks of economy and relationships. This led MIT researchers Erik Brynjolfsson and Andrew McAfee to refer to this era also as “The Second Machine Age”.

I took this picture above from the World Economic Forum’s website (www.weforum.org) because it provides a quick glimpse to all points of impact of the Fourth Industrial Revolution, highlighting the wide range of areas being disrupted in this era. We are witnessing parallel advances in Physical, Digital and Biological fields with an unprecedented pace. Due to the advent of new materials, 3D printing was made possible at the same time that new, smaller and more powerful sensors enabled IoT and inventions such as autonomous vehicles. Industry 4.0, term first brought to the table in the Hannover Fair in 2011, is also being enabled by IoT and the connectedness of the world we live in. Factories can now rely on a wide range of real time data to make decisions and improve their operations. The platform business model has been born and quickly disrupted many industries with the rise of companies like AirBnB, Uber and Alibaba. Such companies match supply and demand owning no assets, reducing their operation costs and also the amount of people needed to handle the operation. As if all of those things were not enough, gene sequencing has dramatically decreased its cost powered by AI and algorithms recently developed. We can see that fields are connected and this connectedness leads us to a dramatic shift in the way we live as a society. The advents of the First Industrial Revolution, for instance, took around 120 years to be widespread across Europe. On the other hand, Internet took around 10 to be spread worldwide. As Klaus Schwab highlights in his book:

Detroit in 1990 (then a major centre of traditional industries) with Silicon Valley in 2014. In 1990, the three biggest companies in Detroit had a combined market capitalization of $36 billion, revenues of $250 billion, and 1.2 million employees. In 2014, the three biggest companies in Silicon Valley had a considerably higher market capitalization ($1.09 trillion), generated roughly the same revenues ($247 billion), but with about 10 times fewer employees.

Schwab, Klaus. The Fourth Industrial Revolution (p. 10). World Economic Forum.

Taking a deeper look into the aspect of revenue x jobs, it may seem more scaring than the fancy side of revolution and technological improvements if not handled throughly. Oxford researches have made a list professions that are most and least likely to be automated in the upcoming years.

We can notice that the jobs least likely to be automated are all related to creativity, mastering human relationships and require a high level of cognitive skills. In contrast, tasks that are performed on a daily basis with a repetitive characteristic are at stake with the development of computers that are capable of replacing and being better than humans at tasks that require rapid and repetitive decision making through the use of algorithms. The set of skills needed to perform roles that are not at stake, though, is a very challenging one. The Future of Jobs Report was published in 2016 by the World Economic Forum and brings us a forecast of the necessary skillset to be relevant in the workplace until 2020, as shown in the picture below:

The main concern here is that the highest share of the world’s population lacks the majority of such skills. A small minority of innovators with high cognitive skills is being able to hit the world with platform products that meet consumers demand worldwide creating global network effects. The possession of intellectual capital is strengthening its value over labour and it causes many workers to be unmotivated as they see no perspective of improvement in their lives. The US Census, for the first time in history, shows that productivity is being enhanced by replacement of workers, instead of the creation of new products that require more workers to operate. This is another difference from the previous industrial revolutions, that used to create new operations and jobs in almost the same share that it has replaced.

Another thing that Klaus Schwab points out in his book is the concern about public and private leadership. If the leaders of the world don’t acknowledge the unconventional aspects of the Fourth Industrial Revolution and embrace their social role in this era, the impact of the current revolution can be as hazardous as the most pessimist ones predict. Not as a coincidence, this is the trigger that made me relate the Fourth Industrial Revolution to Product Management.

Product Management to embrace the revolution

I can bet that if you are a product manager, you are now working with a platform product or at least thinking about it. You don’t need to be aware of the concepts of the revolution to realise that this business model is becoming commoditised and dominating. But, have you ever wondered the impact that such model can have in your organisation and society?

Even though sometimes product people are not formal leaders in organisations, leadership is a great part of what product managers do. So, as I mentioned in the previous paragraph, do you think you are a leader that understand the real impact of your work? Far beyond from delivering new products and features, product managers are also in charge of analysing how teams are preparing their skillset for this new era. When a new feature is delivered, is your company service desk being trained to gather new insights of customers instead of simply asking questions? Is your product team investing in PoCs of sophisticated algorithms or Machine Learning? Do you stimulate engineers of your team to improve their social skills, build relationships to other teams in order to solve complex problems? By doing this, you are not only developing your organisation and society as a whole, but also developing skills that are going to be necessary to implement your product features if you still want to be relevant. Consumer expectations have shifted dramatically, from P2P products to the usage of data to anticipate consumer’s needs. Experiences provided by products like Spotify and Netflix are expected to all industries, not only to entertainment anymore. There is a whole field called Anticipatory Design (you can read this Medium post for further information https://uxdesign.cc/design-experiences-that-are-one-step-ahead-2254e98d07b2) that can be studied to start doing so.

Another thing to be taken into consideration while developing new products is the collaboration between companies, specially if you work in a big one. Whenever you feel you lack the skills to develop something, it is worth taking a look in the marketplace and think about partnerships. Technology has decreased the cost of entry in the market and there are lots of small companies providing services that can be useful for a wide range of products and, in the meantime, fostering new entrants to the market. Regardless the size of your company, collaboration within the company is mandatory for achieving success nowadays. As consumers expectations have rose, so have employees’. Hierarchy will not make your team achieve the best results, but rather collaboration and an environment that stimulates growth.

More directly related to product development, the World Economic Forum’s Global Agenda Council on the Future of Software and Society surveyed in 2015 more than 800 executives and experts of information technology around the globe and asked them about technology breakthroughs they believed would happen until 2025. The table below, taken from Schwab’s book, shows the percentage of respondents who believe in each item of the list. This is a very good source of things to be aware of and grasp opportunities to develop them in your products.

In order to take advantage of such things, product teams must be willing to embrace uncertainty and the possibility of failing. If you think about the first item of the list and try to build some product that connects clothes to the internet, a concern about cybersecurity will also be risen. This is another subject that you and your team need to study to survive in the digital era. We must always question our patterns and operating models and adapt them if we want to fully grasp the potential of the Fourth Industrial Revolution. The term “Agile Government” is also being discussed, as many experts understand that the velocity of our regulators is going to make them obsolete and useless if they don’t rethink the way they do their job. So, even if you face a regulatory issue with your product, why not question it?

At last but not least, I believe empathy is a very important thing for Product Management and User Experience and many Product Managers are masters in this subject. But what if everything we have learned about interacting with each other changes? This concern came into my mind while reading the quote below in Klaus Schwab’s book.

According to MIT’s Sherry Turkle, 44% of
teenagers never unplug, even while playing
sports or having a meal with family or
friends. With face-to-face conversations
crowded out by online interactions, there are
fears that an entire generation of young
people consumed by social media is
struggling to listen, make eye contact or read
body language.

Schwab, Klaus. The Fourth Industrial
Revolution (p. 101). World Economic Forum.

Once again, questioning our patterns (even about the way we empathise) and the way we do things will be crucial to understand and lead this revolution that is all around us. Product People are leaders that need to be deeply aware of the underlying questions of this digital era that is changing the world faster than ever.

I hope this post was insightful about the Fourth Industrial Revolution and the changes that are happening in our world. I’m very glad to share my thoughts with the product community so we can discuss about the role we play in this environment.

Have any thoughts about it? Like, comment and share!

What does the Fourth Industrial Revolution have to do with your product? was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

#1 Fundamentals of Leadership

One of the first things I have learned about leadership is that, even though it is a noun, you should think of it as a verb. Leadership is essentially about dealing with people and their way of being. As they are constantly changing, the way you lead must be always adapting. A true leader can understand the uniqueness of each individual and build relationships over it, not only with the people you like first hand, but with all of the people in the team. Once you understood each one’s uniqueness and built relationships with them, there are two main goals to be accomplished: Develop individuals so they can achieve results; Wisely communicate the vision of the organisation and the connection that it has with the work of the team. It may seem intuitive that a leader’s #1 concern must be the development of the people in the team, but it is easy to be consumed by the day-to-day work and fail to do it with care. The main point here is: Just don’t do it! Another trap that is pretty easy to fall into is not setting a clear vision and outcomes for the team (obviously aligned with what the organisation expects). You can’t expect that an individual with developed professional skills achieves results if there is no clear vision of where to go, and it is also pointless to expect results of a team with a clear vision but without individuals developing themselves.

If you want to go deeper in this subject, I recommend to read the book “How Successful People Lead”.

#2 A brief of Product Management

If you are reading this, you’ve probably seen the picture below about Product Management a thousand times, but let me show it just one more time to reinforce one important thing: Product Management is not about being an expert in UX, Business or Technology, is about letting experts in those fields do their best and facilitate their communication.

Product Managers might, and should, understand about those topics. What happens is that, if a product manager spends his/her time coding, for instance, s/he is probably not dealing well with the key activities of the product manager: Helping the team overcome its roadblocks; Setting, communicating and updating product vision; Creating product strategy; Aligning product vision with the company’s vision; Gaining buy-in from executive level. Do you know which is the most important asset for all those things that Product Management deals with? The answer is: People! It does not matter whether it is your team or other people from your organisation, product managers must put people in the first place. If a product manager helps the team develop itself, the experts of the team will do their best and build a great product. If the product manager is able to align the product vision and strategy to the needs of the company, the product (and the team) will therefore be seen as essential for achieving great organisational results. Product feedback from customer and market-fit can also help to shape the vision of the company.

PS: Doesn’t it sound a lot like leadership?

#3 Product Leadership shaping the company of the future

Mr. Albert Einstein once quoted: “Insanity is doing the same thing over & over again & expecting different results.”

Many of the companies that dictated the market in the past decades didn’t care about product leadership and I assume they wonder why they have to do it now. As I also assume they don’t want to disappear or strive not to, that’s why product leadership is essential to respond to a competitive landscape that has rapid change as the only constant, and I support this thought on Mr. Einstein’s quote. Changes that regard customer needs, employees expectations and society have now a faster pace than ever. This is due to a digital and connected world which is going through the fourth industrial revolution. Regarding this landscape, Product Leadership came to the scene; it sets inspiring vision, cares about individual’s development, creates an inspiring environment to work, and eventually creates breakthrough business models through the combination of such factors. Creating new business models are not a matter of innovation anymore, but rather a matter of survival. There are lots of references about inspiring products that are in line with this thought: Peter Thiel and Salim Ismail, for instance, use different approaches in their books (Exponential Organisations and From Zero to one, respectively) to the same underlying point: Inspiring companies attract, develop and retain the best employees and build inspiring products that customers love. This is Product Leadership! As far as I’m concerned, deep transformations like this require new ways of thinking.

Product Leadership is thus sadly fated to fail if not supported by all levels of an organisation; it cannot rely only on Product Managers. Product Managers can set inspiring vision for their products, but the company’s vision must also be inspiring, supportive to the product level and carefully thought by executive leadership. The first will not be effective without the latter. The strategy of the company can also led to the birth of new products with a first direction, which will be later detailed by product leaders. But the birth of a new product or business unit can only be justified if thought to achieve product leadership, otherwise there is no product manager that will be able to develop a thriving product.

I hope this article was helpful to deepen your understanding about Product Leadership and why it is crucial for companies in our current competitive market.

Have any thoughts about it? Like, comment and share!

It is time to talk about Product Leadership was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you work in a product team or in a digital business, you’ve probably heard a lot about this topic, or might even have lost some sleeping nights due to the lack of it in your daily basis. I think that there is no doubt whether designers and product team should work together and if both of them are essential to achieving great results. This is common sense (at least should be). The real question we struggle to answer is: Why is it so hard to happen in a smooth flow and be something we do not even need to talk about? I have some thoughts about this and I will share with you in the following article.

Different ways of thinking in the workplace

Working with somebody that sees things in a very different way than you do must be taken as a constructive challenge, not as an issue. Having good discussions with different points of view and no pointing fingers is great for doing a good job. The hard thing is that, if you really want things to happen that way, it demands a lot of empathy and also knowledge about yourself. And when I say empathy and knowledge about yourself I really mean it, deeply. Know our background and things that make us who we are is a task harder than you think. It seems pretty obvious that designers and product teams have different ways of thinking, but have you ever wondered why? Nobody is meant to be a designer or engineer as soon as he is delivered from his/her mom’s belly. We are all born human-beings, with some characteristics already inherited from our parents/grandparents and they do matter shaping our personality. However, the choices we make throughout our lives and how we deal with the problems we face are the ones that really shape our character and how we see the world. A designer, for example, may have been interested in arts as a kid and loved to exercise his creativity. An engineer, on the other hand, is someone who may have been interested in math and loved to find solutions for problems. I might be stereotyping a little bit, but this is just to clarify why sometimes it is so hard to reach an agreement with someone who is so different from ourselves. This is just the tip of the iceberg and I will give more examples in the following topics.

Duncan J. Watts’ book “Everything is obvious: *once you know the answer” is a very good read if you want to dig deeper into human behavior and psychological differences between humans.

Education and working skills

So, well, you decide to work as a designer and go find formal training to get your first job, that’s great! Here are some things you are going to learn from day one:

1. Think problem first, not solution first;
2. Have empathy for your users, try to be in their shoes;
3. Whenever you design something, test it with users;
4. You are not your users, so your opinion on what works best is not the rule.

All those lessons are great and I agree with all of them, but let’s now take a look at an engineering training.

You attend to your Computer Science undergrad’s first class and the teacher asks you to:

1. Study programming logic;
2. Study Object Oriented programming principles;
3. Find the best algorithm to solve a specific problem.

So, have you noticed a slight difference between those educational backgrounds? It is one more way of blossoming those differences of thought among people. Things just get worse while working. The main job of a designer is to find the right problem to solve (no matter how much time or effort it takes), the one that is going to make users want to use the product developed by the product team to address this need. Once this problem is established, the product team has the goal to find the best and fastest way to solve this, choose the right technology, develop the best algorithms and a scalable solution with the less amount of effort and time possible. In the meantime, another thing happens and is the next one I want to point out:

Metrics means different things for designers and product teams

One who has already been in an agile environment is aware of agile team metrics, such as the burndown chart, user stories lead time, story points delivered per sprint, the CFD diagram and so one. If done right, they can tell a lot about the team and help finding improvements or even help to estimate how much time it takes to develop something new. While the product team is looking for ways to improve its metrics, designers are trying to design a new onboarding flow that decreases the user quit rate, or a new flow that reduces the time needed to accomplish some task. All those metrics matter and you shouldn’t think otherwise. Trouble just comes up when they happen to be mutually exclusive, and this happens a lot.

Expectations that does not match

Talking about mutually exclusive metrics, it comes to my mind also what’s behind them. Why designers measure such things? My point of view is that they expect long term outcomes: Having great reviews in the app store, creating something innovative, shift the way users used to do something. They don’t really care about the outcome of each team’s sprint. The product team, on the other hand, expects to improve its metrics and have a faster lead time, so that they can release features and products with an excellent time-to-market. They know that the outcome of each sprint is an opportunity for learn something. So the team expects that designers understand this and deliver the prerequisites for the team work.

All that being said, you must be now thinking that designers and product teams came from different planets and they are fated to not be able to collaborate. I would say no, indeed no. Deep inside, designers and product teams share many goals, but they often don’t come to the table as a shared interest, that’s why I call it “Hidden similarities”

Hidden similarities between designers and product teams

The picture above shows the UX Umbrella, and it is possible to see some roles of people that are usually inside product teams. How a product experience can be good if the front-end developer has chosen a programming language that does not support the animations proposed by the visual designer? Or un the other way round, the product team works with a legacy product that does not support heavy visual design and the process of migrating the code is long. What is the point for the visual designer to focus on animations and perfect micro interactions in the short term?

This last sentence is a good example for short-term outputs x long-term outcomes. It is not something bad when designers envision long-term outcomes and product strategy, but product teams need to break this vision into short-term outputs so they can do small pieces of work that will eventually achieve this long-term vision.

At last but not least, I strongly believe that none of us has won the sperm race to be here on earth doing something we are going to be ashamed about. If you disagree with me, maybe your company has hiring problems. So, when you, product team member, is talking to your fellow designer our vice-versa, try to keep this in mind.

Those similarities leads us to some key success factors that, in my point of view, dictate whether you will be able to reach this collaboration or not.

Key success factors for collaboration between designers and product teams

1. Working (actually) lean

Working lean means you will have cycles. So it is pointless to be stuck in the think part or in the make part, you have to commit yourself to go through all the steps, regardless the one you like the most. All those steps must be time-boxed and measured. Designers must hold their anxiety to see that long-term vision implemented and trust the product team that its short-term iterations are the best way to achieve long-term results. This kind of anxiety can be explained by a human cognitive bias called “Hyperbolic discounting”. We tend to attach ourselves into something in our hands instead of something that is yet to come. The product team must not fall in love into a solution already developed, changes are going to happen in the process and they are normal. Our world is dynamic, user’s expectations changes on a daily basis and we need to adapt ourselves. There is another cognitive bias called “Commitment Bias” that explains this. Both designers and product teams must reach together a conclusion about what is the less amount of work that can generate the highest value.

2) Foundational research can’t be a block in the process

Products with no meaning tend to be a huge and fast failure. One of the techniques to reduce this risk is to have good foundational research, with user interviews and market research. However, this process can’t last forever and/or block team’s work. Designers must organize themselves to do this during some project setup step or in parallel to their work with the team. I know this gets even harder nowadays, we are exposed to a huge amount of information that is close to our hands, so the feeling that the perfect research could have been done if we had one more day to do so is hard to avoid, especially for creative minds. This is when the “Paradox of Choice” comes to the table. The double diamond is a good framework designers can use to know when to discard hypothesis and move on to the next one without getting stuck into the same question again and again. I would also suggest designers can have a cup of coffee with some engineer friend and ask how to be more focused on solution :)

3) Iterations of the product team

Iterations of the product team must not be all about measuring burndown charts and story points. The team must ask itself if the product is still solving a user’s real life problem, if real value is being delivered and even if all product’s features are worth to be kept alive. The Pirate Product Metrics (AARRR) from Dave McClure can help the team answering those questions. The team can also talk to designers and learn more about empathy and being in the user’s shoes :)

4) The Product Manager

With all the things I pointed out here, maybe this picture does not need subtitles. If there is somebody who can facilitate work between designers and the product team is the product manager. Product Managers are the ones to understand about UX, Tech and Business, but not being a specialist in none of them, though. This gives to the Product Manager the ability to understand both designers’ and team’s expectations and coordinate activities towards a common goal.

5) Business Leadership

Business Leadership might hurt someone’s ear, but it is essential to have leaders that pay close attention to this collaboration and try to facilitate such dynamic of work. It is not about bossess trying to impose their opinion, but people with experience and sensibility to help designers and teams achieve their results.

I hope this article gave you insights on how to improve your work and how your team or company structures itself to do the job. Collaboration between designers and product teams is a hard topic and there is no silver bullet.

Have any thoughts about it? Like, comment and share!

Collaboration between Designers and Product Teams was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the past few years I had some experiences working as a Product Owner with digital products. Since then, I studied a lot about UX, product management, design thinking, agile, customer experience and a wide range of subjects that are related to delivering a great experience to the user. Studying all of those subjects, there is one thing that I’ve noticed as a pattern: Whichever the article, paper, workshop that you read or attend to, there will always be some sort of steps you need to go through in order to be successful. That is what I´m calling “magical framework”. I can bring as examples the Design Thinking process, the Build-Measure-Learn from Lean Startup, the Double Diamond and so on…

The point is that worklife in large organizations, or even startups, can bring to the table many factors that won’t allow you and your team to follow those steps and, yes, you have to live with this. But do you know what is worse? Your customer does not even care about it! Expectations of the market are getting higher and your product needs to meet them.

So, in this post I want to do the opposite: I won´t give you one more “magical framework”. I want to share my thoughts about what principles lie behind those frameworks and how you can apply them regardless the framework you are using, size of your team/organization and maturity of your product without getting frustrated if you are not able to do everything by the book.

1. Have a clear vision where to go and what your product does

Even if you are not into product development you might have heard this sentence: “If you don´t know where you are going, you are always going in the wrong direction”. This is also true when related to digital products. If you do not have a clear vision of what problems you are trying to solve, you don´t know which features and tasks to prioritize or the value users will notice in your product. In larger or more complex teams this is even worse, because people start doing things that are not connected. You can solve this in very simple ways. An Elevator Pitch might be a good start!

PS: You can also take a look at the MTP from Exponential Organzations (https://exponentialorgs.com/)

2. Have a clear vision of what your product does not do

On a regular basis, many people will come to you and ask for features or improvements based on their opinion. This will happen with your team, stakeholders and users. If you don´t have this in mind, you might end up doing things just because people asked for it, not because it is alligned to your product´s vision. In the image below you can see a simple exercise that will help you building this!

3. Your goals are not your roadmap

Goals and roadmap are (totally) different things. Even though your roadmap must be in line with your goals, goals are more high-level and drive the direction of the product. The product roadmap is made of a list of deliverables to achieve goals. To make this more tangible, OKR´s (Objectives and Key Results) are a good tool to work with mid-term objectives and keep them in mind of all team. You can also take a look at Exponential Organizations to have more examples of OKR´s.

4. A Business Model Canvas is good, but knowing how to monetize your product is essential

Business Model Canvas is a very good and complex tool. There you can see your Key Partners, Activities, Resources, Value Proposition, Channels, Customer Relationships, Customer Segments, Cost Structure and Revenue Streams. All those points are pretty important and can clarify your direction, but many times knowing how you are going to monetize is what makes your product live.

5. Study techniques and work as a toolbox

All techniques and frameworks can teach you something and be useful for a situation that you face during your work. The main challenge for a product manager or leader is to identify which situation requires each technique. Try to apply techniques as painkillers for problems rather than trying to follow a step by step “magical framework”.

6. Know your Customer and target-audience

There is a lot of techniques for doing that. You can go into user interviews, make a quantitative research, market research and I really encourage you to do so. Each technique answers to a different question and has its unique value, but there is one thing that can be less time consuming and give you lots of insights about an audience´s needs: The old and gold competitor´s analysis. In Jaime Levy´s book UX Strategy you can find useful tips about this subject.

7. Remember, you will always have to think about this equation:

I hope this article was helpful to give you insights and tools about how you can drive your team and product better. Also, I´m trying to make you don´t feel frustrated if you think you are not following one of the “magical frameworks”. Your product can still be successful!

Have any thoughts about it? Like, comment and share!

Looking forward for your feedback!

How to deliver great products when you don’t follow any “magical framework” was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.