video1.0<iframe src="https://www.loom.com/embed/be997fb0256b45da8ddca40ee966a053" frameborder="0" width="1920" height="1440" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>14401920Loomhttps://www.loom.com14401920https://cdn.loom.com/sessions/thumbnails/be997fb0256b45da8ddca40ee966a053-1716544726235.gif5015.04# How we build products #### Product & Engineering town hall /assets/randy-fath-ymf4_9Y9S_A-unsplash.jpg background: true Welcome to the first product and engineering town hall. As Christine shared, we will do a monthly Product and engineering town hall. Twice a quarter the content of the town hall is created by you all. We will have demos. Tech talks Learnings from customers Fun. It's also a great, safe place to practice public speaking. Once a quarter it will be leadership sharing insights and perspectives. This is today. Today, we will talk about how we build products. And specifically a change in how we build them. We need to change how we decide what to build. With very limited resources and a huge product context, we must focus on what matters. We cannot spend a quarter on something that does not move the business, but we can also not only optimise what we have today. We have to learn to balance between now and the future. --- # Let's check in Before we get going, we will do a check-in in brake out rooms of four pepole. See you back in 5 min. --- ## New concepts: - Tech Lead - Product team triad - Pitches and betting - Tracking success Today, I will introduce a handful of new concepts that will change how we work. A new role in engineering: Tech lead A new leadership structure in product teams called triads. A new process for how we talk about ideas and prioritise our efforts with clarity. And how we track success. --- ## Today will be crazy #### Sorry! I will share a lot of information today. I was planning to do this as an async Loom video, but the timing lined up to do it in the town hall. This will not be the ongoing format for our Product and engineering town halls. They will be a lot more interactive than this massive download of information. I will talk for almost an hour, and that can be a big drain on our energy. I encourage you to use reactions and the chat as we go to keep up the energy and for me to know that you are still there. We are also recording today so you can go back and re-watch, comment etc, on Loom. All feedback is welcome! --- ## Questions as we go #### Go to Slido.com - enter the code: #3249108 We will use Slido. Please write questions as we go. In the end, I will do a Q&A with NK facilitated by Lars. --- ## The hardcore facts I want to start today by sharing a few hard facts. They are facts that we have to change. And luckily, they are in our control. Today, we will take the first steps to change them. --- ## We are not growing like we should /assets/gabriel-tovar-93iTD1IH34I-unsplash (1).jpg background: true As a business, we have hit a plateau. We need to get off it. We cannot stand still. We grow roughly 2% per quater, that is barly okay, but not where we should be. --- ## Our commercial impact is too low /assets/kazuo-ota-kjWIILfGkOY-unsplash.jpg Product and engineering represent roughly 43% of the company, measured in cost. We also represent a huge part of our commercial success. We are building what we are selling. But the impact we have on building the growth of tomorrow is too low. We need to reset our conversations to always focus on the commercial impact of the products we build. Commercial is delivering on tomorrow's growth, we are building next year's growth. --- ## We should have more developers /assets/brian-mcgowan-ggg_B1MeqQk-unsplash.jpg I often hear: "we need more developers" I can't agree more with you all. We need more developers. Period. Full stop. But as you learned in the last town hall, we don't have the economical engine to hire more developers right now. The awesome thing is that we sit with the powers to make it happen. We have a huge impact on how valuable and impactful our products will be on the business, and the better business, the bigger the budget The more developers. The less time we spend on products that we have already built that don't have an impact, the more time we have to develop new products that can drive revenue later this year. The less time we spend on building new products that turn out not to be impactful, the faster we can increase our engineering headcount. I want us all to be extremely focused on our business impact. Every time you see something and think, "This is a bad use of our time," question it, challenge it, and bring it to us. --- ## Impact /assets/spacex-yJv97tE7GDM-unsplash.jpg background: true I believe the feeling of impact is the biggest motivational driver for a product team. We all want to be impactful. I hear a lot of you say that you lack that feeling. It's hard to know why we have prioritised what we have. It's hard to ship due to complex products. It's hard to manage stakeholders, and feedback comes too late. Let's change this. Let's have an impact together. --- ## ==What== is more important then ==how==. It's strange to start a talk on process by stating that the process is not important. But the truth is that we can't focus on what we build without changing how we build it. Today is the first step towards that. --- ## In our control /assets/jonathan-borba-ouCLfSjMRdE-unsplash.jpg background: true All of the things I just mentioned are within our control to solve. We have to take that control. We have a massive impact on how fast we as a company grow. We can create products with huge commercial impact next quarter, even bigger next year. --- ## I have done this before I have been a part of leading the implementation of everything I share today multiple times before I have even been consulting with other startups and worked directly with Ryan Singer multiple times providing feedback for the upcoming version 2 of shape up, and I am trained by Marty Cagan. This is not just the implementation of something I have read in a book, it's a mixtape of learnings that I have collected over many years. This is not to say that I know all the answers allready, but to share with you all that I have seen it succeed multiple times, and I strongly belive that we have the opportinity to move into a new gear. I also belive that we are in a stronger stating position then most of the companies I have helped in the past. It is going to be challanging, but it's also going to be extreamly fun, both to learn, but also to work in a better way together. I am looking forward to doing this with you all. --- ## I will fail /assets/igor-omilaev-LdJLgZ0rrvA-unsplash.jpg background: true It's a strange job to lead a team this size, to facilitate innovation, to drive change. And I will fail. I will make mistakes. I will let you down. None of it will be due to ill fate. I want to succeed together with every one of you, but I am often wrong. I will give you one promise. I will listen when you think I am wrong. I can't promise that I will change my mind, but I will be open ears and take in your feedback. I invite you all to always reach out to me, NK or whoever on the team you wish to give feedback and talk openly and candidly. This is how we improve. I expect it from you, and you can expect it from me. --- ## 5C's Lets quickly touch on our values in connection to what I want to share today. --- ### Clear A clear what and why Our customers need to clearly understand what we do, and why we do it. Not only the first time they meet us but every time they touch our products. That also means that each thing we build clearly needs to fit together with a tight narrative. We also need to ensure that our products communicate all the complicated things they try to achieve in a way that is extremely clear to our users and customers. We need to improve our marketing and positioning towards our dealer customers in a close relationship with the marketing team. Today, it's very hard to understand what we do without talking to a salesperson. --- ### Courageous We need to dare reach for great. We should have the guts to try big things, to change what we have today. Without courage, we don't move forward. We need to dare try things that likely will fail. We need to have the courage to change how we work. That is what today is all about. We also need to have the courage to have hard conversations about our products, about how we work, about how we each can improve. --- ### Curious We need to talk to users and customers We need to be extremely curious about our users and customers. Our curiosity for our users needs to be a part of our DNA. It is core to our craft that we develop this curiosity even further. --- ### Committed Action! I am asking for one core commitment from all of you; this will not work without it. We need to be committed to action. Without action, we cannot change, without change, we cannot get off the plateau. Today I am starting a lot of action, and I hope you will join me. --- ### Compassion Changing together requires compassion and feedback We are going through a lot of change right now. And that requires a lot of compassion. We need open and honest conversations with each other. We need to develop together. We need to be open-minded and ready for change. --- ## Product team roles /assets/saksham-gangwar-YVgOh8w1R4s-unsplash.jpg background: true We have to start by discussing what roles are in a product team. But first, let's define a product team. It's a team focused on building and maintaining customer-facing products, such as the consumer site, OEM products, and dealership products. We also have pure engineering teams, which we call Platform teams. Today, that is DevOps and Data Engineering. Today will primarily be focused on Product Teams, but some roles and workflows will also cover the Platform Teams. We also have a purely operational team, and I'm sorry, today, there will not be much input for you. However, please still take an active part, as the collaboration between your team and the product and platform teams is very important. --- ### No people managers On a product team, there are no people managers, and the team structure is flat. All people in management sit outside the team, so nobody will sit in the room with their boss when they need to be creative. We have some teams where this can not be reality right now, and that is okay, but we will keep this in mind when we make changes over time. The lack of managers does not mean that there are no leadership roles, the PM is a natural leader of the team, but the leadership mandate is driven by their responsibilities, not by reporting lines. Equally, the tech lead, who I will come back to is not the manager of the developers on the team, they are simply the ones leading the technology. So, let's talk about individual roles. --- ### Product Manager Manages the product, not the project The product manager has to possess deep knowledge about a handful of core areas: - Our Customers and users - Our data - Our business model And - The market we are in In the team, the PM is the representative of all four of those. When you, as a team, are deep in a discussion, the PM needs to bring the perspective of our users, what our data shows, and how it maps to our business and the market we are in. They need to be extremely connected with all stakeholders across the company. The PM needs to have good working relationships with all members of the SLT and individual team members across all departments. The PM needs to understand what drives each stakeholder's goals and how your product can help them achieve their them. The PM also needs to understand what the stakeholders see in the market and what customers the PM should connect with. The PM is also responsible for product adoption. The product manager is also the external spokesperson of the team in town halls, team meetings etc. Lastly, the PM is also responsible for tracking the teams OKRs. --- ### Product Designer The Product Designer's role overlaps very much with the Product Manager's, but they bring the craft of Design, research, prototyping and UX to the table. They interact with users as much as PMs but less with stakeholders. As a product designer, you represent the user, not only from a problem standpoint but also from a solution standpoint. You work closely with engineers and the tech lead on developing the solutions and perfecting what we deliver. --- ### Engineers Engineers on the team are mainly focused on delivering the product. However, you will also be exposed to customers once in a while and invited to participate in discovery, shaping, and moving the product forward. You are not required to participate every time, but you are expected to do so occasionally. --- ### Tech lead They care as much about what they build as they care about how they build it. The Tech Lead is a new role we are introducing today. We don't have any tech leads yet, but we will find one for each product team over the next months. As a tech lead, you are expected to have a deep interest and care for what we build, you have a great product sense, you are opinionated, and you consider working on the "what" outside your code editor a core part of your craft. You will still code, but you will spend half of your time defining the what. --- Get in front of real customers and watch them interact with your products As a tech lead, you thrive with talking to people you don't know. You are curious about what you can learn from interacting with users and customers. You ask questions to drive clear learnings, and you walk away from these interactions energized. Talking to users is not seen as a chore but as the main source of inspiration for what we should build. Most of our innovation will be driven by tech leads. They can apply their amazing technology understanding to problems they, together with the PM and designer, are exposed to. --- #### Keep track of new technology "Is there something that's possible today that solves a problem we've wanted to solve for a long time" - Marty Cagan The tech lead is responsible for keeping up with new technologies and working creatively on how we can apply them to business problems in a way that will drive commercial impact. The business and our commercial success is as big a driver for you as the technology. This is the epicentre of innovation. --- Process is never what's important. The tech lead owns the delivery process, not the PM. You can only have the bandwidth to own this if you believe in a minimalistic pragmatic process based on the empowerment of the team's engineers. The tech leads responsibility is to untangle the team from the process to make sure each engineer can maximise their impact and deliver high quality. At the same time, you find working and optimising the process interesting. --- ### The triad Product Manager + Product Designer + Tech Lead I want to introduce a new concept, the triad. The product team's triad is the leadership team in charge of leading the product. The Product manager, designer, and tech lead form a team that works closely together every day. Later I will get more into some of the ways the triad work, but for now, you should just know that it consist of the PM, Designer and tech lead. --- # Brake Let's take a 5 min brake before we go into what to build. --- # How do we know what to build? /assets/Untitled.jpg background: true Now that we have set the right team, we can move on to the big question: How do we know what to build? The truth is that we don't know, but we need to work hard to minimise our bad bets. We need to find out that we are wrong as early as possible. We will be wrong, and that is okay, but we need to do more work upfront to ensure that we are betting on the right things. --- ## Dual-track agile Historically, we have focused on delivery, the part where we sit down and build. Delivery is very important, but as a company, we only generate value from our delivery efforts if we build the right things. Dual track agile is a simple concept of running both discovery and delivery at the same time. --- ### But what is discovery? /assets/tittee-parichad-WYIeX_WUGDQ-unsplash.jpg Discovery is the act of de-risking our bets. It is a work track that goes on simultaneously while engineering builds in delivery. Product managers, designers, tech leads, and some engineers will spend time shaping ideas, problems, and solutions and finding ways to evaluate their potential and fit with customers. Discovery is where we talk to customers, run experiments, write pitches, and draw wireframes. It is where we open up the solution space, where we challenge what we could build before forming our bets and getting ready to place them. It's all the pre-work that we do to be able to sit down and say, "This is the right bet for us." Some call it discovery, others call it "Shaping" --- ### Shape Up Stop Running in Circles and Ship Work that Matters /assets/Clipboard_1.png size: contain Some of you have already heard of Shape Up, a book by Ryan Singer and Basecamp. We will not follow the book word by word, but there are quite a few elements that we will implement and mix with Dual Track Agile and our own learnings. --- ### Pitches The Pitch is a core part of Shape Up A pitch is a document that outlines an opportunity we could bet on. A pitch describes: - The problem - Our appetite - The solution in a low-fidelity - What success looks like - Any rabbit holes - No-gos --- #### The problem /assets/jackson-simmer-ZxRHtPacwUY-unsplash.jpg background: true The problem outlines what problem a user, company, or customer is experiencing that we could solve. The description is fairly short and to the point. Often backed up with user interviews and data, but sometimes purely described from our subjective experience. --- #### Appetite /assets/alexandre-st-louis-6IUz4w_re8g-unsplash.jpg background: true In my experience implementing Shape Up, the appetite is one of the most powerful concepts but also the hardest to understand. First, we must understand that Basecamp has a strict culture of being firm on deadlines but flexible on scope. We need to build that same culture. So when they talk about appetite, it's the investment we are willing to make into a bet. Putting it in boring business terms: How much money (our time) are we willing to spend on a potential upside? Let's say we could build a feature on the consumer site that would allow users to evaluate a trade-in offer they received from a dealer. The team writing the pitch would have to sit down and come up with an assumption on how valuable that would be for us to have and how many weeks of manpower they are willing to invest in it. As you can see, this is not an estimation of the effort required to build the feature but an assumption of a cutoff point at which it would no longer make sense to invest in it. Of course, we need to evaluate whether it's realistic to deliver the solution within the appetite. If not, it's easy peasy: We don't even have to work more on the pitch; we can archive it. Appetite is a concept that we will have to learn to work with and adapt to our own style, but when we do, it will guide many of our decisions. --- ### The solution /assets/ee_breadboard-f576c579fcb3f3865a3004c9e9e53fd0c97fa14e65a7b81af3ec6fbfe7b31832.png size: contain It's important to get the solution part of the pitch right; the most important thing is to hit the right fidelity. This is not a high-resolution Figma design. It's hardly a wireframe. Ryan Singer has developed some great tools for expressing solutions in a way that makes it easy to understand the potential but doesn't dictate to the team how the final product should be. Most importantly, it is not expensive to develop and throw out. Some of the concepts are fat marker sketches and breadboards but are better described by Ryan directly, so I will not spend too much time here. The balance to get right is to foster a shared understanding that can drive a debate without going deep into details. I encourage you to read chapter 4 of Shape Up, "Finding Elements". The chapter covers two great concepts: Breadboards and fat marker sketches. --- #### What success looks like - Weekly evaluations - Clickouts to recommend better deals - Weekly signups from the flow What success looks like is a part of the pitch format I have added. Basecamp is running a different business than we are. We need to be more performance-oriented. How does our SRP drive click-outs? How many leads are generated by the test drive widgets, etc.? In this section, the team will describe what success looks like in raw numbers and how we will track it. In the example of the trade-in evaluation tool on the consumer site described before, success could be defined as: - Weekly evaluations - Clickouts to recommend better deals - Weekly signups from the flow The success criteria depend heavily on the solution, so we should always ensure that we track them well and follow up on them after going live. The success needs to be aligned with our OKRs. We should also not be blinded by numbers only. One of the biggest challenges for a modern product organisation is to balance product sense and data. If we always lead by numbers, we can end up over-optimizing. If we always lead by-product sense, we can build the wrong things. We have to balance the two. --- ### Rabbit holes /assets/mounzer-8yk3kJoGJ7E-unsplash.jpg background: true Rabbit holes are areas we already know have the potential to make the solution more complex, stuff that we need to navigate around to keep it simple and deliver within the appetite. --- ### No-gos /assets/tom-prejeant-eMTLooPQKPU-unsplash.jpg background: true No-gos are ideas that we already know about, often great ideas, that we will not include in this pitch. It's important to have conversations about the limitations of what we are building. I have often moved ideas back and forth between the solution and no-gos. This is how we keep to our appetite, and become flexible on scope. This is where we cut the fat. --- ### The superpower of a pitch /assets/tk-qJDkJRTedNw-unsplash.jpg background: true A superpower of a great pitch is the shared understanding across the company created by the pitch. The pitch contains everything someone needs to understand what and why we are building a feature. The pitch should be a living document that follows the new feature from its inception until it is live and we have evaluated the success criteria. --- ## Betting table /assets/carl-raw-7H7KVCihBvI-unsplash.jpg background: true The Betting table is a meeting for each team before a cycle starts. We review the pitches that the team brings forward and evaluate them against our OKRs and our vision. At the meeting, we decide what pitches we should bet on. The team must bring more pitches than we have time to build, so we don't stack the cards going into the meeting and make sure we have some hard decisions to make. At the betting table sits the triad of the product team, Me, NK, and Johan. For platform teams will be represented by the team lead. I am the final decision maker in the meeting, but in my experience, the decisions are clear and easy 95% of the time, and I don't need to drive them. The betting table takes place a few days before a new cycle starts. --- ## OKRs and betting table OKRs guide what we should focus on. They should not define what we build. It's my responsibility at the betting table to make sure we bet on the things I think will have the biggest impact on the key results we are trying to move. --- ## Cycles /assets/abdullah-ahmad-uG4VizVyURs-unsplash.jpg background: true We will stop doing two-week sprints and change to five-week cycles with one week of cooldown in between. This fits with our goal-setting rhythm of quarterly OKRs. We will do this in both product and platform teams. Two cycles to each quarter. Why longer cycles? Each cycle or sprint has an overhead of planning. The smaller the cycle, the more planning. What is also true is that the smaller the cycle, the less autonomous the team can be. --- ## Cool-down /assets/scott-rodgerson-PteeDvACFak-unsplash.jpg background: true Cool-down is a period where we have no planned work. In our case, it will be one week right after each cycle. During this time, the triad is fully engaged in planning what to do in the next cycle together with leadership. Engineers spend the time on bugs, technical debt projects, learning new skills and exploring new ideas. --- ## Are we not solving bugs for five weeks?! /assets/evgeniy-prokofiev-pWBgujijtGI-unsplash.jpg background: true Bugs that are discovered during a cycle are not default priorities right now. If it's a severe bug, fix it. If it's a bug you introduced as part of your current work, fix it. But if it is an old non-severe bug, don't. Record it and get back to your list of bugs doing cool-down. The tech lead owns what bugs to fix and when to do so. --- ## Bi-weekly team check-ins Every two weeks, we will have a check-in with each team, not only product teams. Present at the check-ins will be: - Me - NK And for product teams, Joao will also join. The triad will represent product teams, platform teams will only be represented by the team lead. The agenda will be: - Check-in on OKRs and KPIs - Demo and status of what's in delivery - Run through of what's being shaped in discovery - Any team dynamic issues - and iterations on how we work. The purpose of the meeting is to make sure feedback runs fast between leadership and the team, and that information sharing is not happening in the silo of 1:1s. If the team feel the need, they can always invite for a check-in off schedule. --- ## Tracking success /assets/maxim-hopman-fiXLQXAhCfk-unsplash.jpg background: true As I just mentioned, in the bi-weekly meeting, we will discuss metrics, OKRs, and KPIs. --- ### KPIs How we know our engine is running What are KPIs? KPIs are your health score within your team's context. They are the dashboard of numbers that you can briefly look at every day and know that everything is fine. A well-developed set of KPIs for a team gives the freedom to focus on driving a change elsewhere. For the consumer team, KPIs could measure things like: - Click engagement - Bounce rate - Paid click conversion rate And lots more. KPIs will always have green, yellow, and red scores. If green, do nothing. If yellow, do a light investigation and keep an eye on it. If the number is red, the team should stop everything they do (including cycle work) and focus on stabilising it. The KPIs should always be available for everybody to see. Tobias is leading the effort to develop KPIs across the company before Q3. Every team will have to co-create a set of KPIs with NK and me, and all KPIs should be automated as they are not often changing. This means that we have to pick up this work now. --- ### OKRs The change we are focused on making OKRs are the change we are focused on driving right now. OKRs are a way of expressing the short-term strategy we are working on; they describe what success looks like when we have achieved it. We will not achieve all OKRs, and that is fine. We will have to change OKRs as we learn, and that is also fine. Some OKRs will run longer than a quarter, and some will run shorter. Most OKRs will have to be tracked manually. Do it every Monday and use the information to evaluate what needs to happen this week in the team to make sure we achieve the OKRs. --- ### Tracking productivity and innovation I don't believe that tracking productivity and innovation directly in a product and engineering team is viable. We are doing creative work, we are not a factory. Measuring lines of code written does not work, Measuring time in front of a screen is just plain wrong. We do know some of the actions needed to foster productivity and innovation. Actions that are leading indicators for creating a space where productivity and innovation can happen. We know that we all need to seek inspiration externally. We know that getting in front of customers and talking to them is foundational to innovation. I don't want a big heavy process to measure this and try to achieve a utopia of perfect data. I am primarily interested in how we can do our best to create conditions for productivity and innovation. For this we will lean on Culture Amp. --- ### Productivity Currently: 89% Goal: 95% /assets/CleanShot 2024-05-09 at 09.01.22 2@2x.png size: contain We ask five questions about productivity. I am primarily interested in the feeling of productivity, but we will track productivity as an overall score. Right now, that score sits at 89%, that's really good! My goal is to get above 95%. I also know that all the changes I am introducing today will have a short-term negative impact on our productivity as we have to learn something new. But I believe we can get productivity even higher when we change how we work. --- ### Innovation Currently: ==77%== Goal: 90% /assets/CleanShot 2024-05-09 at 09.06.15@2x.png size: contain We also track innovation in CultureAmp with two questions. One question is focused on our ability to transfer new ideas into reality. Here, we are tracking at 85%, which is acceptable. I also hope that the journey of changes we start today will improve our skills at this. Where we are not doing too well is in how often we spend time seeking inspiration and knowledge, here we only hit 70%. We need to do better here. It's a huge part of our job. --- ### Share what you learn #team-product-and-engineering I encourage you all to share blog posts, books, podcasts, and YouTube videos in our team channel weekly. When you read something a co-worker shared, add your perspective or even just a reaction to the thread. Thomas and Cristian are great at sharing exciting reads, commenting, and debating in Slack. I would love to see more of this from all of us. /assets/CleanShot 2024-05-09 at 09.28.25@2x.png size: contain Seeking inspiration does not come without effort and hard priorities, please find the space need. I personally start every day reading an article or two, and when I stumble on an interesting read I save it for when I have time to read it. --- ### Talking to customers Dealer team: "Most weeks I participate in live conversations with consumers and dealerships" Currently: ? Goal: 90% I have already spoken quite a bit about the importance of talking to customers. As you can hear, this is close to my heart. We will add a team-specific measurement in Culture Amp of customer interactions to all product and platform teams. For the deal team the question will be: "Most weeks I participate in live conversations with consumers and dealerships". I will make sure to write a version of that question adopted to each teams customers. In the consumer team, it's talking to consumers and our traffic customers. The data team and DevOps is talking to internal customers in Autouncle. My goal is to get this score above ==90%==. Everybody needs to participate in customer conversation, including me, NK, designers, managers, and engineers. You don't need to be the one leading the conversation—it is totally fine to sit back and just take notes—but you need to be in the conversation, not just watch a recording. This is not a requirement to do every day, but I expect you all to spend a minimum of 30 min every week on this. PMs, tech leads and designers, it's on your shoulders to ensure that this is possible, invite your team to listen in, make optional invitations and facilitate capturing everybody's thoughts after conversations. It's not the first time I am introducing this in an organisation, and I know that it will not be easy, but what I have seen before is that it will transform how we talk about what we build I also know that it will be a huge motivational driver, You will experience the impact you have directly. I don't expect us to get to 90% straight away, my goal is to be there within a year. --- ### Engagement Currently: 88% Goal: 90% /assets/Trend chart for AUTOUNCLE ApS . Check-in survey April 2024.png size: contain The three measures I just mentioned are our core metrics, but we don't want to over-index for them. To counterbalance it, we will still track the overall engagement score and monitor each sub-category closely. The goal for the engagement score is to get above 90%, we are almost there. --- ### We should not cheat ourselves I want to stress that the biggest weakness of leaning on CultureAmp data for tracking ourselves is the danger in self-reporting data. I sit here today and tell you that hitting a specific level on each parameter will require even more from us all in making a real check-in in CultureAmp. I have one wish: Rather score too low than too high! None of us learn and get better if we don't have the right signals. The score we end up with is my responsibility, it is not a measurement of your performance. This is the feedback I need to navigate the changes with you all. --- # Rome was not built in one day /assets/caleb-miller-0Bs3et8FYyg-unsplash.jpg background: true I don't believe that by me sharing all this information today will lead to us changing everything tomorrow. It will take time for us all to develop a process that is both adopted and adapted to our needs and how we want to build. What I shared today is our starting point, not the last itteration. --- ### What happens next week? - Q3 company OKRs defined by SLT - First team check-ins - Start work on KPI dashboard - First customer conversations with a broader team presence - Information deck and inspiration shared Next week the SLT will define Q3 company OKRs. With those as input we will have the first team check-ins where we also start to discuss what team OKRs should be for Q3. We will also discuss the KPI dashboard and start to develop that. In the teams, you must start connecting with customers if you don't already do it. Remember to invite your team members. --- ### What happens next month? - June: Pitch writing - June 24-27th: Betting tables - July 1th: First cycle starts In June we will write the first pitches and give feedback on them. In the last week of june, we have the first betting tables. The first cycles will always be rough, there is a lot for us to learn and we have to get used to a new process, this is both expected and fine. --- ### What happens in Q3? - Q3: Find tech leads for Consumer and Deal team Doing Q3 NK, Joao and I will work on selecting tech leads for the consumer and deal team. We will start by writing an in-depth description of the responsibilities and share that broadly. --- ### Recap - Tech Lead - Product team triad - Pitches and betting - Tracking success Today I have introduced a lot of new concepts. The tech lead. The person who sits in the intersection between users and technology. Product team triads - The three musketeers who are driving discovery in a product team. Pitches and betting - how we are going to communicate ideas and decide what to prioritise. and lastly, how we track success, leaning on what we already have and adding the measurement of customer interactions. From here we will iterate together adapting all of this to what works for Autouncle. I can't wait to get my hands dirty together with you all. --- # Book recommendations Shape Up by Ryan Singer and Basecamp Inspired by Marty Cagan Transformed by Marty Cagan Continuous Discovery Habits - Teresa Torres Deploy Empathy by Michele Hansen The Mom Test by Rob Fitzpatrick Escaping the Build Trap by Melissa Perry Next week I will share more inspirations and input, but if you are already hungry for more here is a list of the best books on the topic that I have read. I think Shape Up is a must-read for us all, it's quick and easy. If you have never participated in customer conversations before I would also encourage you to read The Mom Test or Deply Empathy. --- # Q&A #### Go to Slido.com - enter the code: #3249108 /assets/edwin-andrade-6liebVeAfrY-unsplash.jpg background: true Let's take a 5 min brake where you have time to add questions to slido, and then Lars will facilitate the Q&A.