00:00:14.650
Hello everyone. Today, I would like to talk about breaking silos in product development. My name is Raphaela Wrede.
00:00:19.820
I'm a Ruby developer who transitioned into an engineering manager, and I'm from Berlin. I'm currently working at Contentful, and previously at Travesty and Babel.
00:00:26.360
I'm also a part-time student of sociology and political sciences, as well as a lover of Berlin currywurst, among other cuisines.
00:00:33.949
What I want to emphasize is that these two aspects—my background and interests—actually complement each other quite well.
00:00:41.720
Now, joking aside, let's get back to my talk. I want to start by showing you how real-life projects from my personal career have felt. Let's look at Project A.
00:01:31.920
In this instance, my disempowered team was assigned predefined work. Unfortunately, the work felt uninspiring, and the feature idea didn't have the team's buy-in.
00:01:35.320
This lack of buy-in stemmed from the team's belief that this feature wasn't actually something the customer wanted. Although some customers had been asking for the feature, there wasn't sufficient quantitative data to prove that a large enough portion truly needed it.
00:01:46.360
Unfortunately, the complexity of building this feature was quite high. It required several of the company's most senior engineers to spend months shipping a first version to finally test customer adoption and the initial assumptions of the product manager.
00:02:01.100
The return on investment for this project was a complete disaster. Lots of money was wasted, and the team's morale was significantly affected. Now, let's take a look at Project B.
00:02:48.990
In the second example, my team was given a high-level objective and some business context without predefined solutions—similar to the concept of 'the goal.' We had the freedom to come up with potential solutions.
00:03:01.620
A diverse mix of people from support, product design, engineering, user research, and analytics spent five days in a room together, aided by a professional facilitator. We brainstormed ideas, discussed them, and engaged in rapid prototyping, even testing the prototypes with real customers by the end of the week.
00:03:42.210
This process is known as the design sprint, invented at Google. After five days, the team chose to implement a feature they regarded as low-hanging fruit in terms of complexity, while also promising to solve the problem at hand.
00:04:02.850
Within two weeks, the team tested customer adoption on production to determine if it was worth investing more time in the idea. As you might have seen from these two examples, the difference in team engagement and the unfolding development process was very noticeable, making it quite eye-opening for me.
00:04:39.060
Project B was also significantly less risky due to early user testing. While books like 'The Lean Startup' by Eric Ries have been popular for over a decade, it's unfortunate that many products are still developed in the problematic way exemplified by Project A.
00:05:19.980
I've worked on numerous projects like Project A, and it has consistently been frustrating and demotivating for me and the teams I've been part of. I could never forget how different it felt when we executed the design sprint for Project B, which felt creative, empowering, and engaging.
00:05:55.170
This was a much more mature and elevated way of collaborating as a team. Consequently, I became increasingly interested in understanding how the truly great companies effectively manage product development.
00:06:36.390
I thought about innovative companies like Amazon, Apple, and Google, and questioned what allowed them to create environments that foster innovation and creativity.
00:06:55.500
I also sought to understand how these companies ensure that they invest their time wisely, focusing only on the most promising ideas. Therefore, I began conducting extensive research on product management.
00:07:31.710
I've subscribed to various product podcasts, read popular books on the topic, and watched product talks online. Over time, I developed a much better understanding of effective product management practices.
00:08:05.580
I discovered a significant discrepancy between mediocre and excellent product companies in terms of their approaches. If I've done a good job with this talk so far, you might be curious to learn even more.
00:08:44.990
Now, how is product development done right? Unfortunately, I have to tell you that there is no silver bullet, and I don't have a simple recipe for you to follow.
00:09:00.600
However, I have found that great product organizations share certain principles and patterns. Interestingly, these companies can have very different cultures; innovative companies like Amazon, Google, and Apple have distinct company cultures.
00:09:24.750
Despite these cultural differences, some ingredients and principles are shared, forming the basis of strong product cultures. Let's examine some shared principles.
00:09:56.470
I have identified four key principles for this talk that have frequently emerged in my research. First, great product organizations distinguish between two main phases of work: product discovery and product delivery.
00:10:34.140
Conversely, mediocre companies often focus exclusively on product delivery. For instance, Scrum is typically centered only around the delivery aspect.
00:10:51.000
During the discovery phase, evidence is gathered to differentiate viable ideas from poor ones. This entails conducting a series of experiments using rapid prototyping to uncover solutions to given problems.
00:11:04.970
The purpose of product discovery is to address four critical risks when developing digital products: value risk (will the user buy the product?), usability risk (can the user understand how to use it?), feasibility risk (can we build it?), and business viability risk (does the solution benefit our business?).
00:11:38.860
Addressing these risks requires that the product management team—driving this effort—engage experts from various departments early in the process.
00:12:07.240
For instance, you might consult the design and UX teams to navigate usability risk or involve engineers to assess feasibility risk. If an idea seems promising during product discovery, it will eventually make it onto the product roadmap for prioritization in the delivery workstream.
00:12:34.290
If discovery is executed correctly, ideally no more than one-third of your original ideas should progress to delivery. Most ideas are typically not viable; if many ideas are approved for delivery, it indicates something is going wrong, often wasting time and resources.
00:12:55.500
Secondly, top product organizations maintain a fast-paced experimentation mindset. Instead of precisely detailing solutions beforehand, they make short, strategic bets by evaluating how much they are willing to invest in a solution for a specific problem.
00:13:21.460
Teams are granted the autonomy to experiment and devise solutions that can be developed within an established timeframe. They also continuously assess the success of shipped work through metrics defined in advance, integrating user event tracking directly into the product from the onset.
00:13:49.990
Methods like A/B testing and involving analytics and user research are employed to determine if it is worthwhile to iterate further on current solutions.
00:14:06.420
Moreover, successful product teams display the courage to discontinue features that are underperforming and haven't yielded desired results. This decision is often challenging but is necessary in order to simplify the user interface and codebase.
00:14:47.560
I've observed this frequently, and it's unfortunate how many companies clutter their codebases with underutilized features that are retained indefinitely, causing unnecessary maintenance work.
00:15:12.940
Notably, in great product cultures, learning from such failures is seen as a success in its own right, because the organization has still gained insights to inform future decisions.
00:15:51.440
Next, effective product cultures empower their teams and grant them autonomy. Empowered teams are frequently assigned problems rather than fully developed work and are responsible for crafting precise solutions.
00:16:21.350
While this approach may not be feasible for every task, it can be extremely beneficial for certain problem types. Facilitated brainstorming techniques are particularly useful here.
00:16:48.440
For instance, in my current company, we heavily utilize user story mapping sessions and design sprints for specific challenges. Working in this manner ultimately comes down to one crucial element: trust.
00:17:05.880
It is imperative that management hires individuals they can trust, and then steps back from micromanaging these highly skilled experts. A prerequisite for successful autonomous teams is a cross-functional staffing approach that includes individuals with appropriate seniority and competence.
00:17:37.340
This independence from external resources lets them operate as effectively as possible. To avoid descending into creative chaos, effective product organizations provide their autonomous teams with a clear business context, enabling them to make informed decisions.
00:18:10.140
One effective method is to structure teams around customer-centric missions, focusing on aspects of the user journey or specific customer personas. This approach ensures that teams become true experts in particular product areas, maintaining focus on customer needs.
00:18:59.800
Another approach is to implement an OKR framework to align departments and teams, establishing high-level objectives that contribute toward an overarching company strategy. Such systems promote outcome-oriented or mission-driven work over output-oriented methods.
00:19:37.740
This distinction is also reflected in the language and terminology associated with poor versus great product cultures. You might encounter a top-down approach contrasted with a more collaborative approach, or the differentiation between a project mindset and a product mindset.
00:19:55.210
Today, I believe that as engineers, we should become more knowledgeable about how outstanding products are created. Of course, we need to keep learning about various technologies as they evolve rapidly.
00:20:24.050
Nonetheless, it’s equally important to recognize how significantly our work environment and the building of software products impact us.
00:20:47.550
If this environment isn't innovative or engaging, and we are often stuck developing features that nobody wanted, it does not matter what technology we’re using.
00:20:59.500
So I encourage you to broaden your knowledge about product management.
00:21:00.000
Interestingly, while we talk a lot about T-shaping ourselves as engineers, I wonder why we often neglect learning about product management.
00:21:03.500
This craft heavily influences our work life.
00:21:05.050
Being informed about these topics will better equip you to ask the right questions in job interviews.
00:21:07.050
This knowledge will help you find a great product company as your next employer.
00:21:09.730
Additionally, I’ve attended numerous tech conferences and meetups, yet I’ve never encountered a talk focused on product management or product discovery.
00:21:26.250
So, thank you for allowing me to present this slightly unconventional talk at a tech conference.
00:21:30.200
Today, I'm convinced we need to break down silos between engineering and product and, instead, build bridges that improve our product organizations.
00:21:37.060
We must enhance our understanding of state-of-the-art product discovery and management to bridge the considerable gap between mediocre and outstanding companies.
00:22:00.000
If we don’t do this, we risk watching our unoriginal product companies disappear or be overtaken by more innovative competitors.
00:22:36.400
And that is a scenario we surely want to avoid. Thank you very much.
00:22:50.000
If you want to read more, I will later publish the slides. Here are some resources I found very helpful.
00:23:00.000
If you have questions or would like to discuss further, please feel free to approach me later. Thank you.