I had a few wake up calls a while back.
The first came when I was looking at some photos of myself, I looked really chubby. It was somewhat unexpected. I didn’t think of myself as overweight, and didn’t see that when I looked in the mirror, but there it was — photographic evidence.
The second big wake up call came when I purchased a smart scale. It was an Amazon lightning deal, and I got it on somewhat of a whim. I like technology and like data, so it seemed like an interesting thing to do. But when I stepped on the scale and went through some of the analysis, not only did it confirm what the photos had shown, but took away all possible excuses. Not only was I overweight, but I was flabby and soft too. Well outside of the weight range for my height, way too much visceral fat, a slow metabolism, weak bones, and on and on. I could no longer use the excuse that the camera adds 10 pounds or that muscle is heavier than fat. I had to face reality.
We can certainly debate the accuracy of photographs and consumer smart scales, but that isn’t the point here. The point is that I needed to change. I needed to lose weight and get into shape. Not only for myself but for my wife and my kids. I wanted to be a fit husband and the kind of dad that my kids would not only be proud of, but would want to emulate.
So that is what kicked off my journey. This post is a bit different than my usual writing. I’m not a fitness writer and probably won’t become one. But this is about the things that worked for me. I know that they won’t work for everyone. So if you’re reading this and disagree, you’re probably right in some way. Your mileage may vary and you’ll need to find the things that work for you.
But these are the steps that worked extremely well for me. I’ve lost around 35 pounds and am much more fit and lean than ever before (including my high school and college days). And the main reason I am writing this because a person very close to me asked for some help and guidance. So this is mostly for them. But if there is something useful, hopefully others will be able to leverage it as well.
1. Measure, Track, & Monitor
The first step to making any change is to start to take measurements. As the saying goes, it is difficult to change what you don’t measure.
Get a Smart Scale
To start, get yourself a smart scale and start weighing yourself. This will help establish a baseline and allow you to track progress and trends. I use Eufy. There are lots of good ones based on Amazon reviews. I haven’t tried out many others, but mine was $25 and works perfectly for what I need. I weigh myself every day at the same time so I can keep track of my progress and my trends over time. This helped me establish a baseline and begin to actually monitor my progress as I began to make changes.
Track Your Movement
I’ve been a Fitbit user since the very first wristband came out. Way back when it was just 5 dots and no one had any idea what you were wearing on your wrist. I’m a big believer in it. Tracking your activity level and sleep will help establish a baseline that you can build from.
I’ve personally set a goal of 10,000 steps each day. That tends to be a stretch for me most days. It gets me going outside to walk around the office complex a few times a day (it’s about 1,000 steps to make a full loop). I wouldn’t otherwise do that.
I don’t think there is anything magical about 10,000 steps. But understanding where you are currently and then setting a stretch goal is the real key. Once you have measured your current activity, you can then start to set those stretch goals and actually get moving.
Track Your Eating
To truly make a change, you have to track what you’re eating. I’ve used MyFitnessPal for this, though there are other good apps as well. Enter everything into it, even if you don’t change anything to start. Simply understanding what and how much you’re eating will be critical to making changes.
This may feel onerous to start. And it is. However, you won’t have to do this forever. This is meant to help you get started. Once you’ve established the right habits (more on that below), you’ll likely be able to scale this back. But it is critical to get started. You’ll likely be surprised at how much you’re eating every day. I know I was shocked when I started tracking my food. It helped me make a few changes right off the bat, though that hadn’t been my intention.
Tie It All Together to Monitor
There are numerous apps that can bring everything together for you. As a Fitbit user, that one has worked well for me. I also use Google Fit to see some of my trends, including weight trends since I can add my smart scale to it. Whether it is a single app or multiple apps, use technology to your advantage. I’ve tended to use a variety of apps since each have their own strength. You can certainly tie them together though since many of them have integrations with each other (though not all of them, so don’t expect to get your Fitbit data into Google Fit for example).
2. Eat Right — Diet Is Key
I used to believe that exercise was the most important key to fitness. With that mindset, I used to exercise frequently with little regard to what I ate. When that didn’t work, I continued to increase my level of exercise more and more, spinning my wheels endlessly. At the same time I was spinning, my wife was taking the opposite approach. She didn’t have a massive exercise regimen like I did, but focused on eating right, both in quantity and quality. And she managed to lose weight and look great. This was especially pronounced after she gave birth to our kids. She was able to rapidly return to her pre-pregnancy weight while I struggled to do anything.
When I switched to a similar mindset, I was actually able to make massive progress.
Control the Quality
The first key to eating right is to focus on the quality of the food you consume.
When I started really focusing on my eating, I wasn’t as concerned about the amount of food as much as I was concerned about getting the food right. For me, that meant switching to a Keto-style diet. I’ve long believed that fat and meat and those types of food are significantly better for you (check out The Big Fat Surprise for a fascinating read about the history of dietary guidance). A Keto diet focuses on cutting out most of the carbs and sugars in your diet and replacing them primarily with fat and protein.
I started scrambling some eggs for breakfast every morning. I started to cut out breads and carbs in other meals wherever I could. I also switched some of my snacks from crackers (I love Ritz Bitz) to nuts like almonds.
At first, I didn’t even cut back too much on how much food I was eating. I simply started by replacing foods and eating better. That massively helped the transition and got my body ready for bigger changes.
Now I’m not a Keto purist, and I may be missing some of the benefits of that. I still have some sweets and some carbs and some things occasionally that aren’t the best. But I do believe in the principles and have found that the closer I can align to a Keto diet, the better I’ve done and the better I’ve felt.
Control the QuantityMy next focus was on reducing the quantity of food. Once I established a baseline for my daily calories and food intake, I started to scale back.
My first step was to cut out a lot of junk food. I noticed (by tracking) that I ate a lot of sugary foods. I have a sweet tooth, and anyone who knows me can attest. So starting to limit myself to a few treats a day was the first step.
Next, started to cut out other snacks. I found (again, by tracking) that I ate a lot of snacks. My meals were pretty normal sized, but I ate a few meals worth of calories each day just in snacks. So cutting that back was a key to success.
Start Intermittent Fasting
I’d heard about the benefits of fasting for some time, but hadn’t really tried it until more recently. And it was a huge boost to my weight loss.
The idea behind intermittent fasting is that going without food for an extended period of time forces your body to use its fat stores (rather than the food in your system) for energy. So you start to use up that stored fat. It also helps decrease your insulin, which also helps your body start to use its fat stores as energy. A good start may be 12 hours of fasting, while going up to 14–16 hours is often the goal of many folks. There are other combinations as well, but I haven’t tried those.
I’ve seen the benefit fasting for myself. Not only have I been able to lose weight, but I’ve also been able to lower my body fat, and I largely attribute that to fasting. I still haven’t even fully optimized my fasting routine either, so I hope that as I get better at it, I’ll see even more benefits.
Personally, I started my intermittent fasting by ending snacks in the evening. We usually finish dinner around 6:00 pm, so that is when I finish eating for the day. This was a huge change in itself because I always used to eat in the evening. And not healthy food. I know some folks skip breakfast, but I never have done that. I have my scrambled eggs around 7:30 am (sometimes 8:00 am if I’m lucky enough). That typically gives me around 14 hours of fasting, which I’ve found to be great. If you can push that further, go for it. The key for me was cutting out evening snacks (and desserts). Other people aren’t breakfast people. I have a friend who prefers to eat in the evening and skip breakfast. That has worked for him. Personally, I’m a breakfast person. But the key is narrowing the window of time you’re eating on a given day.
3. Exercise — Resistance Training First
Another misconception I had a while ago was that cardio was key to weight loss and fitness. When I didn’t see results with cardio, I doubled down, often skipping lifting days to do more cardio. It was a vicious cycle.
Lifting and Resistance Training
The reality is that strength training is more important than cardio in my experience. If you have to choose, choose to lift or do resistance training over the cardio. When I made that switch, I started (gradually) to see much better results. The great thing with strength training is that it compounds over time. By increasing your muscle mass you can increase your metabolism and actually burn more calories at rest. Which is the dream, right? Actually being able to burn more calories by not having to constantly be exercising.
Cardio and Steps
That’s not to say that you shouldn’t do cardio type exercise. Like I mentioned above, moving is really important. Doing it every day is important, especially if you sit at a desk all day like most of us.
Additionally, I’ve found that switching to high-intensity intervals is better than simply hopping on the elliptical every day. So as I’ve done cardio, I’ve been doing my normal cardio routine for about 3 minutes, and then I kick up my speed and resistance for 30 seconds, basically sprinting for a short burst. Then going back to a jog.
By chance, I also found out that having rest days was critical for me. For a time, I was exercising every day. However, as my schedule got busier I had to start taking some evenings (I exercise in the evenings) for other work. Against my expectations, that actually seemed to jumpstart my progress in losing weight. I don’t know if I wasn’t getting as much out of my workouts by doing them each day or if I just needed some extra rest, but I’d suggest making sure that you have some rest days. Keep up with the steps, but try and do it throughout the day and take a break during your normal workout time. The key takeaway for me is that I didn’t have to exercise every single day to see results. I could actually have time for other things as well, as long as I was getting the most out of my workouts and eating right.
4. Push Through
One of the most difficult things is getting started. You’ve likely created habits that you have to start to break. Your body is going to be upset with you. I know that as I started to make changes, my body rebelled against me. I had overwhelming cravings for all things sweet. I occasionally binged on ice cream or pie or cookie dough.
The exciting thing about getting started, though, is that you’ll likely see some good progress up front. As you make some changes, you probably have some room to lose weight. Which will help you get going. Use that momentum!
It does get easier. But you will also hit some plateaus along the way. I hit several plateaus as I moved toward my target weight and fitness. It was hard to break through.
First, stick with it. As you focus on eating well, exercising and doing the things you need, you will be able to make progress, even if it seems slow or stalled.
Second, it may be worth it to “juice up” your returns by going to more extreme lengths for short periods of time. I’ve done this by completely cutting out snacks (even healthy ones) and any dessert/treats for a period of time. I’ve gone extra hard during my workouts and made a big push to get through. This has usually worked for me and has allowed me to then get back to my regular, sustainable routine but at a new, lower weight.
5. Create New Habits
None of the things I’ve talked about above are easy. They’re actually really hard. To be successful, you have to literally rewire your brain.
I found that giving up an evening snack was massively difficult. My body had gotten accustomed to eating around 9:00 pm every day. Breaking that habit was hard. But I established the habit of not eating after 6:00 pm, and now it’s hardly a temptation.
The ultimate goal of all of this is to change your lifestyle. It has to be long-term to be sustainable. You can’t starve yourself indefinitely, so you need to adjust your body and your habits to make these changes sustainable.
Hide the Food
Willpower is a muscle. You can build its strength over time, but you can exhaust it on any given day.
I know that when my favorite treats are out on the counter, I’m much more likely to snack on something than when it is hidden in the pantry. Make things easy on yourself, and don’t leave your favorite snacks out. Even better, stop buying some of those things. It is much easier to avoid Oreos if you don’t have any Oreos.
Create a Workout Routine
This is something that I did a long time ago, and it is a habit that has served me well. I’ve tried workouts at all different times of the day, but have found that the evening is best for me. The kids are in bed and I’ve done everything else I need. When 9:00 pm comes around on Tuesday, Thursday, and Saturday, that is my workout time.
Find the time and days that work best for you and then make them a habit. No excuses because you’ve already planned for this time. Once it’s not in questions, it becomes so much easier.
And do something you enjoy while you workout. One of the few times I watch TV or movies is during my workout. It’s basically the only way I can keep up with any shows or Netflix. I’ve also gotten through a ton of audiobooks while working out. Find something you enjoy and add it to your workout.
Make Switches Wherever You Can
Swapping out breakfast food for eggs was a big change for me. But a couple of scrambled eggs in the morning are now a habit for me. It’s easy now. I eat eggs for breakfast.
Make these types of switches wherever you can. Get a big thing of Costco chicken strips and take those for lunch every day. I do something similar to that now. I’ve made a few switches where I’m in control and that gives me some more flexibility where I don’t have as much control (such as family dinners).
Be Intentional & Mindful
I’ve found that being intentional and mindful is another key to success. It is easy to mindlessly snack while watching TV or staring at your phone. I alwayseat more when I’m not paying attention. So pay attention! When you’re eating, take it slower. Focus on what you’re doing. Don’t zone out to the TV with a bag of chips. Even if you only intended on having a few, you will end up eating the whole bag before you realize it.
Stick With It
The biggest key is to great some routines and stick with them, even when it is difficult and even when you’re not seeing quick results. The goal isn’t to lose tons of weight immediately — it’s to create a new you. So make the changes, however small, and keep them going. The funny thing is that you’ll look back in 3 months and see tons of actual progress, even if it felt like you didn’t make any progress day to day. That is how my experience was. By sticking with it, you’ll be able to see massive (albeit gradual) changes too.
Nothing about this is easy, though some items are easier than others. The picture above is my actual trendline for this year. It is even more dramatic if you look at last year as well. It’s been an incredible journey, but it has taken time and commitment.
At the end of the day, you can do this. It may take some time, but don’t get discouraged. You’ve done harder things than this. You’ve survived much more difficult things. You can do this!
In my post about Product Thinking vs. Project Thinking, I highlight the differences between the two mindsets. Fundamentally, project thinking is about outputs and timelines while product thinking is focused on outcomes and solutions. And while there are instances where project management is critical, applying project thinking (or project management) to the entire lifecycle of product development is incredibly problematic.
And that is what I see with SAFe (Scaled Agile Framework if you’re unfamiliar with the term). While its intentions may be good — and there may even be companies or situations where it is helpful — as a whole, SAFe is the wrong answer. It may be a project management dream come true, but the issues with SAFe are numerous and significant.
From a practical perspective, there are several issues.
Layers of Process. SAFe adds layers of process to product development that don’t need to be there. For example, Program Increment Planning (PI) is a formalized process by which all teams plan out and discuss their deliverables for the next quarter and align with all other groups. It is a formal meeting that takes place for several days. Now, this may sound good on its face because communication like this is a good thing, as is the planning and understanding that can result from it. But the process by which it is accomplished makes it overly burdensome in practice and takes away a team’s agility both by forcing the set meetings at the set time, and by locking in many of the commitments of those meetings with little wiggle room after the fact.
By putting so much focus on the structured meetings and process, it also takes away the emphasis on continual learning. Discovery shouldn’t be happening once a quarter, but continuously. Same with prioritization. Locking in these important aspects of product development to be done only at specified times does a real disservice to teams.
Generally speaking, if you look at the diagrams and processes outlined for SAFe, you can easily understand why the entire thing is overly burdensome and complex. Rather than simplifying or streamlining, it bogs down the entire development cycle with unnecessary processes.
Layers of Management. In addition to the heaviness of the process, SAFe also add (or keeps) layers of management throughout the development process. From the development teams to release train engineers to epic owners and beyond. The many layers of management reflect the many layers of process, complicating the overall workflow and adding a lot of cooks to the kitchen. While this may look incredibly appealing to managers, centralizing a lot of control at each level, the reality of having so many hands involved is often confusion and slow-downs as everyone steps on each other’s toes and each group may have different ways of doing things.
Additionally, it removes too many teams and people from the impact of their work. Instead of having a product owner or team responsible for features, and another layer responsible for business communication and yet another layer responsible for market needs, a development team should know and understand all of those facets. How can anyone be expected to truly deliver value to users beings so far removed?
Stagnation. In some regards, SAFe could be considered remedial agile. I never like to get into the debates about what is agile and what isn’t — they tend to be unproductive and pointless — but SAFe isn’t about scaling agile for large organizations in the sense that it takes agile principles and applies them to large groups. Rather, it is about beginning to apply some agile principles to large organizations that have no other agile experience. This could be great for a large company that is steeped in processes and waterfall methodology. But if SAFe is the end rather than a stepping stone in the process, it will ultimately result in stagnation of teams and products.
From a more philosophical perspective, the issues are even greater.
Focus on Methodology. SAFe begs for the focus to be on the methodology itself. With the heavy processes and prescriptions, it’s almost necessary. This, of course, isn’t unique to SAFe. It is a fundamental issue with many methodologies: the process becomes an end unto itself. Scrum has the same problem, where the focus too often drifts from creating value for users to optimizing the development process, as measured by story points, velocity, etc. Optimizing may be important, but it is a means to an end, not an end itself.
Lack of Autonomy. Second, rather than giving autonomy to teams, SAFe removes autonomy from teams and ties them down often to lists of features. Part of PI often involves determining the features of the next 3 months. That isn’t necessarily a bad thing, but it becomes an issue by locking a team into features rather than outcomes. SAFe also ties all teams together into release trains and other processes. Rather than allowing a team to function independently — experimenting, releasing, and learning — teams are all formally tied together and dependent on each other. Decisions that may have otherwise been able to be made independently are now constrained by the process.
Lack of Agility. The purpose of agile is to allow teams to be, well, agile. That means allowing teams to design, build, test, learn, and iterate. The focus is on outcomes, which may or may not be achieved by certain features. Having agility means being able to shift priority or feature in order to better deliver the outcomes. It allows teams to learn from their experiments and then make adjustments as they go. This type of agility is the antithesis of the planning and processes imposed by SAFe and project thinking in general.
Hiding the Real Issues. Finally, rather than addressing the real underlying issues, many of which are described above, SAFe can cover them up with its processes and prescriptions. If an issue an organization faces is too many interdependencies among teams, SAFe’s prescription adds lots of planning and coordination between those team prior to having work begin. That is great if those dependencies can’t be decoupled. But what about organizations where they can and should be decoupled? Rather than tackle the hard work of reducing complexity, we paint over it with more meetings and processes.
That includes complexity from a product as well as from a people structure. If there is too much hierarchy within an organization, SAFe realigns it, but doesn’t fix it. The real issue is likely too much structure already, and the solution may be to flatten the organization so that people can actually have ownership of their work.
Finally, rather than fostering better communication up and down the chain, SAFe adds too many layers. If the real issue is executive communication and buy-in, SAFe may seem like a good answer with its processes and pyramid structure. But it doesn’t address the underlying issue, which may be a lack of understanding or a lack of real involvement from executive leaders.
Theoretically, SAFe is meant to solve some real problems for teams and organizations. Unfortunately, it fails in too many regards in practice. By overburdening teams with heavy processes and prescriptions, it ultimately takes away too much autonomy and agility. Rather than supporting product development teams, it asks that product teams support all the layers of management above. This isn’t unique to SAFe, and managers too often have their roles backward in thinking their teams are meant to support management rather than the other way around, but it is ingrained in the process.
SAFe is another embodiment of project thinking. While product thinking is the solution for product development, it is easy to slip back into a project mindset where the goal is to map out features and outputs and then simply focus on delivering them on a specific timeline. And that is what SAFe does: it puts the focus on outputs rather than outcomes. Success is measured on committing to features and then delivering them throughout the quarter. Of course, this is great if you’re right about all your guesses ahead of time, but that won’t generally be the case. And when processes take the place of outcomes, it’s not good for teams, organizations, or users.
Ultimately, the focus should be on the users of our products and services. We should eliminate as many processes and constraints as possible to better allow our product teams to deliver value. That means reducing complexity and organizational overhead, not adding to it. Get the right people and the right goals, then get things out of their way. Principles will scale to any size, so get those right and you’ll find the right scaled structure.
In some recent conversations I’ve had, the idea of leadership has come up numerous times. From my own leadership philosophy to the leadership (or lack thereof) of those in positions of influence, I’ve had the chance to analyze leadership from several angles. This has led me to reflect on my own views of leadership, and how I’ve implemented those principles.
I wrote about the importance of establishing a leadership philosophy in my article 6 Questions for Determining Your Leadership Philosophy. As part of that process, I spent some serious time determining my own leadership philosophy and its core underlying principles. I wanted to dive deeper into it here, as a way of articulating my ideas and hopefully as a useful reference for others as they establish their own leadership philosophy.
My Leadership Philosophy
Get the right people working on the right thing in the right way — and get everything else out of their way.
The above statement is what I distilled from the principles below. It summarizes what I consider to be my key beliefs and how I view leadership, incorporating my core principles.
Leadership for me really is about getting the right people, creating a vision for what we’re doing and helping establish the criteria and roadmap for success. And then getting things (and often yourself) out of the way.
I didn’t start out with this summary though. I actually went through the process I outlined in my other article and began establishing principles that I believed were core to leadership, and my views on leadership. After several iterations, I refined my thinking to the principles below.
My Leadership Principles
Get the right people
When it comes to companies, teams, or even projects, having the right people is the first key. It’s even more important than having a vision, because without the right people, you aren’t going to reach your vision regardless of how compelling it is.
In the essential book, Good to Great, Jim Collins talks about how successful leaders (Level 5 leaders as they are referred to in the book) get the right people on the bus before doing anything else.
“The executives who ignited the transformations from good to great did not first figure out where to drive the bus and then get people to take it there. No, they first got the right people on the bus (and the wrong people off the bus) and then figured out where to drive it."
This isn’t just for executives of large companies. It is for every team and group. The right people will make or break a product. You could have the greatest idea for a world-changing product. But without the right group, you simply won’t get there. That’s why as a leader, I think it’s crucial to find and keep the best people. I added the idea of keeping them because the best people will have lots of opportunities elsewhere. So you have to actively work to keep them within your organization. Unsurprisingly, teams that stay together longer perform better.
So how do you get the right people? While this isn’t an exhaustive list, I’ve found at least a few key ideas to be critical:
People truly are the key to success, so this principle really can’t be overemphasized.
Establish Principles & Live Them
“When values are clear, decisions are easy” — Walt Disney
As a leader, I believe it is critical to establish personal and leadership principles, and to live by them.
Leadership principles. Part of this is the exercise here — creating a leadership philosophy. Without the right principles, you won’t fully understand the actions your taking.
Team principles. As a leader, it is also important to establish the principles of the team or organization. This helps guide the overall culture mentioned above, and sets the tone for autonomy. If groups can understand the overall guiding principles, they can make decisions for themselves based on those principles.
Personal principles. Finally, a leader should have personal principles that they live by. This may seem like somewhat of a dated notion, but it’s something that teams, organizations, and the world need — leaders who have good fundamental principles, such as honesty and integrity, that they live by.
Set The Vision
“ If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”That above quote by Antoine de Saint Exupéry (though it has a variety of different translations) really captures the essence of setting a vision. A leader shouldn’t be set on divvying up work and creating silos where each group is “optimized” for their task. Rather, a leader should inspire everyone towards a common goal. The vision is the driver, the inspiration that everyone is working towards.
Jeff Bezos has put it well when he says that we should be stubborn on the vision, flexible on the details. All too often we see managers being stubborn on the details (from how we use story points to how teams run meetings) while disregarding the vision. That’s the opposite of what a leader needs to do.
Define The Framework
Of course, it’s not necessarily enough to paint an amazing picture of the future that we want to create. As leaders, we do need to help establish the framework for success. While a vision may be years away, we obviously need to do work now that will move us in that direction.
I’ve long been a fan of Objectives and Key Results (OKRs) for this exact purpose. If you’re looking for some good books on this subject, I’d highly suggest Measure What Matters and Radical Focus, which are great reads.
Creating OKRs allows you and your teams to establish what matters most (objectives) and how you're going to measure whether you’ve achieved your objectives (the key results). This allows flexibility in how the objectives are achieved, but ensures that the most important things are getting the right attention.
By defining the framework, you can unleash the creativity of your teams to find the best solutions. This helps guide work toward the vision, but allows groups to be much more autonomous in how they work.
Give Continuous Feedback & Recognition
It is critical to give ongoing feedback to teams and team members. There is simply no other way for people to improve than to understand real-time what is working and what isn’t, so they can adjust accordingly.
The idea of an annual or semi-annual performance review is probably one of the most antiquated notions at this point. And the sooner it dies, the better off we’ll all be.
It amazes me that over 10 years ago, as a manager at the computer labs at BYU, my fellow managers and I had implemented a feedback system that is far superior to what many companies still use today. We actually had a mechanism for all employees to give real-time feedback to each other. That feedback could then be conveyed via managers or supervisors on a weekly basis. We were also doing a more formal review quarterly. But little of that information was new since it was being delivered continuously. Improvement was an ongoing thing.
In Measure What Matters, this is the type of system advocated along with OKRs. It is called Continuous Performance Management.
“To power positive business results, implement ongoing CFRs (conversations, feedback, and recognition) in concert with structured goal setting. Transparent OKRs make coaching more concrete and useful. Continuous CFRs keep day-to-day work on point and genuinely collaborative.”It’s also critical to give recognition as well. Different people will appreciate this in different ways, so it’s important to understand individuals. But everyone needs recognition. And leaders need to find ways to give that recognition.
Get Everything Else Out Of The Way
Finally, the last key principle is to get everything else out of the way. That often includes managers and leaders. Once you’ve got the right people on the bus, have set the vision and framework, you really need to allow them to do their thing.
In Powerful, Patty McCord’s excellent book about Netflix culture (that I actually started and finished after writing most of my thoughts here), she describes one of the keys of their success as eliminating as much process and overhead as possible. Policies and structures can’t anticipate needs and opportunities.
That’s why I included the quote at the beginning from Steve Jobs. It’s critical to get obstacles out of the way of great employees. And often that includes getting leaders and managers out of the way. Fundamentally, each layer of management should be in place to support those folks on the ground doing the work — not the other way around. If we find ourselves adding work because someone needs an additional report (or something to that effect), we’re doing it wrong. Leadership needs to be in support of the vision and the work, not a barrier to it.
As I’ve had the chance to really think through my own philosophy and the underlying principles, it has helped me clarify my own leadership ideas as well as better understand how I expect my own leaders and managers to function. I expect that this will be subject to update as I continue to add experiences, but these underlying principles form a solid foundation from which to build, at least for me.
I’ve had multiple occasions recently to reflect on my own leadership philosophy. Not only have I been asked about it explicitly, but in several conversations with friends and others, the topic of leadership has come up with both positive and negative examples. This got me examining my leadership style and the principles that make up my overall philosophy.
Reflecting on your philosophy can be a surprisingly useful exercise, because we don’t often examine many of the underlying tenets that govern our actions. But as we do reflect on it, we can begin to uncover not only our own beliefs and principles, but also the principles we value in our own leaders and managers.
So What is a Leadership Philosophy?
When I think of a philosophy in general, it is the set of principles and beliefs that govern our actions and direction. It is made up of many different pieces that are all intertwined, guiding us through various situations.
So a leadership philosophy is made up of the core principles that govern the actions of a leader. Not only what they do, but the vision that they set and the policies they put in place to guide others.
I often see “philosophy” confused for “style”. While style will be influenced by philosophy, they are not the same. Style may be the implementation of philosophy, but it is not equivalent. Additionally, style can be much more determined by situation while the underlying philosophy, though subject to reflection and revision, should not be changing situationally. It should be much more resilient and all-purpose.
Why Determine Your Leadership Philosophy?
Everyone has a philosophy, even if they don’t determine explicitly what it is. All of our thoughts and actions, especially when it comes to leadership, govern our direction. So even without determining or reflecting on a leadership philosophy, you have one. You just may not know exactly what it is or how it drives your decisions.
By taking time to reflect (and write out) your philosophy, you can begin to have a much better understanding of the forces driving your decisions and leadership.
Additionally, you can start to measure where your philosophy and implementation may not be aligned. Are there practices you currently have as a leader that don’t measure up to where you’d like to be? Determining your philosophy and reflecting on it gives you the perfect opportunity to ensure they are aligned. Or what you may need to do if they aren’t aligned.
But what if you aren’t currently in a leadership or management role? For product managers reading this, hopefully you already recognize that even without managerial authority, you are in a critical leadership role. For others, I’d likely argue that you too are in positions of leadership, even if it’s not readily apparent.
Regardless, most of us likely have managers and leaders in some capacity. By understanding our own leadership philosophy, we can better recognize the underlying principles guiding our managers. This is important for working with managers and fulfilling our responsibilities. But it is also critical in determining where we will work best. If your leaders and managers don’t have principles that align with your own, how can you expect to do your best work long-term? Ensuring that we determine our own philosophy and then find leaders who also align with our principles is crucial to our individual success and happiness.
How to Determine a Leadership Philosophy?
As I was thinking about this topic and fleshing out my own philosophy, I asked myself a series of questions that helped me begin to articulate my own philosophy. Here are some of the topics I used to help me determine my philosophy:
What is My Leadership Philosophy?
As I’ve had the opportunity to reflect on the principles of leadership that I value, I’ve been able to articulate my overarching philosophy and the underlying principles. I go more in-depth on my own philosophy in my post My Leadership Philosophy & Principles, but I’ll summarize it here as well:
Get the right people working on the right thing in the right way — and get everything else out of their way.
The key underlying principles for my philosophy are:
Not only is this the way I try and lead, but it is how I want to be led as well. Understanding that and articulating it are critical as I continue to lead various teams and take on more leadership roles, but also in understanding the kinds of leaders I want to work with.
As you begin to reflect on your own leadership philosophy, you’ll begin to set the stage not only for how you lead others, but the kind of leaders you work with. I’m convinced that if more leaders and managers would reflect on their own philosophy as well, we’d begin to see significant changes across companies and teams. So let’s all begin to be that change by understanding our own philosophies and creating the kinds of teams and organizations that everyone will admire.
Influence is probably one of the most valuable currencies as a product manager. Because you likely don’t have a lot of authority, you have to rely on your ability to understand others and help them understand your perspective and ideas.
A key part to influence is having and inspiring confidence. You must first be confident in what you’re doing and what you’re proposing to do. You also have to gain the confidence of your product team, since they are relying heavily on you for the success of the overall product. You need the confidence of your stakeholders and users as well.
So how do you gain confidence in yourself and inspire confidence in others?
Confidence in Yourself
No one will have a lot of confidence in you if you don’t have confidence in yourself. So be incredibly confident, but also incredibly self-aware. Because taken too far, you’ll lose a lot of credibility if you’re unjustly overconfident or arrogant.
Gaining confidence starts with a big dose of humility. I talk a lot about this process in my post about credibility deposits. By definition, you aren’t an expert initially. But you can get there. And as a product manager, you are expected to get there. It starts with acknowledging that you have a lot to learn and then setting out to learn it.
I’ve personally come into almost every product and project as somewhat of a novice. Years ago when I was working with the Money Markets and Liquidity team at Goldman Sachs, I knew very little about the products and environment. But I became an expert in the products we were offering as well as each piece of regulation and how it would impact our products. When new rules were released by the SEC, I went through nearly 1,000 pages in the course of a few days in order to review and understand the implications.
The same can be said for current products I work on. But as I’ve first sought to understand everything from start to finish, I’ve been able to build up not only credibility, but confidence. As you really dive in and get out of your comfort zone, you’ll be incredibly uncomfortable for a while. But that’s what it takes.
Another real key in this process is taking ownership. While the CEO analogy for product managers isn’t perfect, it is an apt comparison in terms of the knowledge you should have and the care you should take with your team, product, users, and stakeholders.
Confidence from your Team
As a product manager, it is critical to gain the confidence of the entire product team. You will be working together day-in and day-out. The success of everyone in that group is tied together. You succeed or fail as a team. So how can you gain the confidence of the group?
Understand. Take time to understand the team. Understand how they work and who they are. Every team is different, so don’t assume that you understand until you’ve taken the time.
Dive In. I’ve found that one of the best ways to gain confidence from the developers, designers, and fellow product managers you’re working with is to dive in. Head first. Get your hands dirty in any way you can. You’ll likely make some missteps, but that’s okay. That’s how you learn.
One thing that I’ve found to be incredibly valuable is to really be in the trenches, even when it’s not necessarily where you add the most value. I’ve been on the late night pager duty, taking the 2am phone calls when something breaks. And even without being able to really fix anything, staying up all night until it’s resolved. Really being part of a team means being part of it all the way.
Develop Technical Expertise. There is certainly a lot of debate on how technical a product manager needs to be, and it depends on the role and company. But more technical skills are rarely bad. And being able to code and understand the nuances of development go a long way in helping you gain the confidence of the other technical folks around you. Just don’t forget who the experts are.
Confidence from Stakeholders
Depending on the size of your organization, you may have a few key stakeholders or you may have dozens. Certainly as the size of the group increases, so does the complexity. But the principles remain the same.
Again, you need to gain an in-depth understanding of each stakeholder. This time it goes beyond the understanding that you gained for your team though. Because each stakeholder will have different priorities, needs, and styles of working. You won’t necessarily be aligned completely like your development team is. As I’ve worked with a wide variety of stakeholders across different organizations, I’ve founds that I have to continually tailor my approach. Here are some key considerations:
Understand the Business. As a product manager you need a broad understanding of the organization. That includes not only how your product impacts different groups, but how those groups then impact other groups as well. Without understanding the business and how everything aligns, you won’t be able to gain the confidence you need from the stakeholders in those areas.
Understand the Priorities and Constraints. Each group, department, or stakeholder will have different priorities. Hopefully these all align broadly with the business, but the reality is that they may not. You need to understand this. Often there may be competing priorities in different groups that can impact your product or team. You have to also understand the constraints that your stakeholders are operating under. Often there will be budget implications, results they are responsible for, or other difficulties they have. How can you expect to sell the vision of your product or get a stakeholder on board if you don’t understand the constraints they are under.
On the flip side though, by showing that you understand stakeholders priorities and constraints, you can gain a tremendous amount of confidence. For example, in one product launch that I did, we had to coordinate closely with another team in order to be successful in our release. However, they were incredibly short-staffed at the time. So working closely with the key stakeholder in that group, we were able understand their constraints, find the right level of help, and coordinate the right timing. It was a tough process. And it set us back from our target. But it was the right decision and ultimately earned us a great deal of confidence not just from that group, but from many others across the organization.
Understand the Individuals. Understanding individuals means understanding who they are, how they prefer to communicate, and what level of involvement they have or need to have.
This could potentially be one of the most difficult areas to navigate. And I’ve found that no matter how careful you are, you’ll likely run into trouble here (so don’t beat yourself up). Because everyone is different. Some stakeholders are very hands-on while others are largely detached. Some prefer quick summaries of highlights, others want to know all the details. Very much like tailoring roadmaps, you have to tailor communication and involvement.
A word of caution as well. Don’t assume that little involvement or delegation means that the stakeholder doesn’t need to be involved. It may seem that way, but there are few things that grind a product to a halt as quickly as a stakeholder coming in from the wings because they haven’t been involved enough. Err on the side of too much communication and too much follow-up.
Confidence from Users
Finally, and maybe most importantly, you need to gain the confidence of your users. This is such a broad reaching topic that it could likely be many posts all on its own, especially across a product’s life cycle. But we’ll hit a few key points here.
Understand your Users. You need to understand your users. Empathize with them. Know what their problems are and what they need from your product. This will not only help you deliver a great product, but will help you gain confidence along the way.
Get them Involved. Do user testing early and often. Find your users or potential users and watch them use your product. Get their feedback. This is probably one of the best ways you can truly understand your users and deliver value to them. It goes beyond the metrics and gets to real understanding by watching real people really use your product.
Err on Their Side. If there is ever a choice between erring on the side of the business and erring on the side of the user, err on the side of the user. Every time. For one, you won’t have a business for long without users, but it will also show how serious you are about their experience. It will build their confidence in you and what you’re doing for them. Hopefully you won’t have to make this type of call often. But you definitely don’t want to be remembered for selling out your users for the sake of your business (*cough* Facebook).
Deliver Value. Ultimately it comes down to delivering value to your users. Knowing what problems they’re solving and helping them solve those problems. Once you’ve done that, you’ll already have gained the confidence of some users. Build on that value and continue to deliver.
Inspiring confidence as a product manager is critical. Without it, you won’t be able to accomplish much. But as you gain confidence in yourself and inspire the confidence of your team, your stakeholders, and your users, you’ll be able to work magic. And that’s what keeps most of us here, and what makes the role of product manager so exciting.
In our current day and age, we are constantly bombarded with new information. It is more accessible than ever before, and we’re constantly awash in data, metrics, news, reports, etc. How much of it is truly valuable though? How much of what is around us every day is truly an actionable signal versus what is just noise?
It’s hard enough to answer some of these questions in our day-to-day lives. It can become even more difficult as a product manager as you’ve instrumented your products and are constantly paying close attention to the huge variety of metrics that are available to us. From latency to active users to monthly revenue to everything else. There is a lot of information available. But what is most valuable? And over what time period? And who decides?
I spent a good deal of my early career in financial markets. There probably isn’t a better example of data overload than in finance. The sheer volume of data available is astounding. And the pace at which you can get it is overwhelming. New reports are available every day with economic indicators, financial forecasts, analyst rating, price movements, and much more. And add the fact that CNBC is on all day long, you have the perfect recipe for information overload.
So how can you make sense of all of that information? How do you trade on it? The short answer is that you don’t. You simply can’t. If you tried to, you’d be thrashed around hour by hour and end up losing significant amounts of money.
While I never traded professionally (for better or worse), most good traders I had the opportunity to work closely with had key pieces of information they’d use. A way to separate out the signal from the noise. A way to create an investment thesis using key pieces of information that actually move the needle, and then make adjustments based on additional inputs they’d get. Whether that is certain ratios for stocks, or certain spreads and purchasing patterns for bonds, there are some key signals that stand out from the noise and can give real insight into markets.
We’re Not Great at Separating Signals from Noise
Despite knowing this, we all fall victim to overconfidence based on noise.
In a fascinating study done by Paul Slovic (and described really well by Adam Robinson in a podcast found here), a group of professional horse race handicappers were gathered to see how well they could predict outcomes based on a number of factors. At first, they were only allowed to pick 5 pieces of key information about the horses and then were asked to make their predictions. Using just the 5 key things they knew, they were able to correctly predict nearly 20% of the time, which is well above what we would expect from chance. They were also roughly 20% confident in their predictions. Not bad.
The key part of the study came as more information was added. Each handicapper was allowed to pick more and more data. As they did, their confidence in their predictions increased while their actual results stayed roughly the same.
Despite knowing more information, they were not able to better predict the outcomes, though their confidence nearly doubled.
More Information Isn’t Necessarily Better
I’ve been asked throughout my product experience to put together numerous slide decks and reports with significant amounts of data about our products. Our team is often asked the same. Numerous charts with all the information about our applications that people feel is relevant to see and understand. The specific metrics of interest often vary depending on the manager and what they care most about (often based on their background or experience). But there are always numerous problems with this.
First, by paying attention to every metric or piece of information, we’re essentially paying attention to nothing. The true signals get lost in the noise. In a multiple page dashboard of metrics, what are the important things? CNBC has to fill up an entire day with reporting and information. That doesn’t mean that it’s meaningful. There are probably days when nothing should be reported because it’s all noise. But that’s not how the world works. We may be asked to fill out a whole host of metrics for our products. But that may not be the right thing either.
Second, we end up focusing on the wrong things. Often in reports or slide decks, the main things that get attention can be the wrong things. For example, if a specific metric isn’t great or isn’t known well, it can get an outsize amount of attention. We may then focus our attention on making that metric better simply because its lack of information got the attention of upper-level management, when it is likely not significant overall.
Third, we can get into data paralysis. By requiring more and more data before we make a decision, we may never end up making a decision at all. One of my teams nearly had this happen to us with an executive who wanted to analyze (nearly to death) a vendor selection. He required months of work and literally dozens of pages of analysis for what amounted to a relatively insignificant decision. In the end, the decision was made by inertia since we had already selected a vendor to pilot with, and it became too late to make any changes anyway.
Finally, on the flip side of paralysis, we can fall victim to overconfidence. Like the study above, we feel like with all the information available we have a good handle on things. Pages and pages of data must mean that we can be 100% confident, right? It’s that kind of overconfidence in the data that can lead to catastrophic outcomes. Because rather than understanding that we may only be 50% confident in an outcome and manage it accordingly, we go in with 100% confidence and are unprepared for the unexpected.
Does that mean we shouldn’t care about our data or metrics? Should we not instrument our products? Of course not. We need data and metrics. But we have to make sure we’re making decisions and doing work based on the most important metrics.
What Can We Do?
So given the pitfalls above, what can we do?
First, we have to understand our biases. I was on a bit of a psychology kick a few months ago, and my reading included some great books including Behave and You Are Not So Smart. It is fascinating to me to analyze our own thinking and understand some of the areas where we may fall victim. For example, the latter book dives into a number of fallacies we may commit. One is finding too many patterns in randomness. It happens more then we think, especially with all the data we have. And we can start to correlate unrelated data points, leading to potential wrong conclusions. But when we understand where the pitfalls are, we can at least acknowledge them, if not avoid them. We can see when we risk being more tuned into the noise.
Second, we have to elevate the important. Not every metric is equal or even important. We have to help key stakeholders and managers understand that. Be confident as a product manager! (More on that soon.) You know your product. You know the important things. While certain stakeholders may want to see certain metrics based on their background or point of view or department, we have to ensure that those metrics don’t take the place of the really important ones.
In order to help with that, it is great to explicitly establish what is important and why. A great way to do that is with OKRs (objectives and key results), which I’m a big fan of. (Check out Measure What Matters or Radical Focus for some good reading on OKRs). By calling out the key things our teams are focused on, we can avoid getting sidetracked with other things. Earlier this year I made a concerted effort to do this for our product. While there are many metrics we’d like to move and that are important, by calling out one, and only one, we’ve been able to keep the focus on the main goal. And while we don’t want certain other indicators to slip, when we have to make a trade-off, it is clear to everyone what we’ll do. And that’s the point.
Trade-offs will always have to be made in product development. But having a clear goal or objective allows us to make those trade-offs. If we had 15 metrics that were all equal, we would constantly be pulled in the direction of the loudest metric (or voice) at the time. And that’s no way to do product development.
Finally, we have to accept that data don’t make decisions. Signals have to be interpreted, and there is inherently a human element to that. No matter how much data we have, it cannot make a decision for us, nor should it. Understanding the most important things, synthesizing that information, and determining actionable steps can be just as much art as it is science.
There is an ever-increasing amount of noise all around us. From metrics to voices to everything else, it is increasingly difficult to identify the important. It takes a deliberate effort to not only understand what is truly a signal, but then to ensure that we aren’t getting lost in the sea of noise. It’s an artful balancing act, especially in product development. But that’s part of what makes it so exciting and fun.
At the end of every year I like to take a look back at some of the highlights. Things that happened personally & professionally, things I learned, books I read, products I loved, etc. So here is one of those posts.
This year I had the chance to try out a bunch of new products (and some older products). So in keeping with the tradition I started last year, I wanted to take a moment to review some of my favorites from 2018. Not necessarily bleeding edge things, but things that made my life better.
So those are my top picks for this year. I have a handful of other runner-ups such as the Echo Show and Echo Spot, which have been surprisingly good. Seeing Alexa with a screen has made it clear how much better it is being able to interact with voice and with touch. The screen has saved us a couple of times as calendar events have popped up, reminding us we need to get the kids to an evening class. The Eufy Smart Scale is another one. I can’t vouch for the accuracy of smart scales in general, but having it connected to your phone and fitness apps makes things so much easier. And the price on this one is quite reasonable for the quality.
I’ve already started working on potential products for 2019, and am looking forward to reporting back what I’ve found over the next year!
At the end of every year I like to take a look back at some of the highlights. Things that happened personally & professionally, things I learned, books I read, products I loved, etc. So here is one of those posts.
My reading list from 2018 was fairly broad, as I love everything from science fiction to history to product management. And this year had some great reads from all of those categories. As 2018 draws to a close, I wanted to take a look back at some of my favorites and most influential reads from the past year.
1. Behave: The Biology of Humans at Our Best and Worst This was probably one of my favorites from 2018 as it was endlessly fascinating and actually led me to explore some other books around similar topics, such as The Willpower Instinct, You Are Not So Smart, and Mindset: The New Psychology of Success. The interaction between our genes, our environment, our ancestry and every other possible factor combines to make us who we are. It’s such a beautiful and profound complexity.
2. Inspired: How to Create Products Customers Love
For anyone familiar with some of my other posts regarding product management, this book won’t come as a surprise. It is one of my top reads for product managers and has profoundly influenced the way I work. I’ve probably read it through a couple times this year as I’ve referred back to it in various scenarios. If you’re a product manager or involved in product development, this is one you’ll want.
3. Foundation Series: Foundation, Foundation and Empire, Second Foundation
This series is incredible. I hadn’t read any of Isaac Asimov until this year, and I was blown away with how great this was. The original stories were published in 1942, which is crazy to think about. But it’s amazing how futuristic they still seem even today. If you enjoy science fiction, I’d highly recommend them. And I’ve already got more Asimov books in my backlog ready to go soon.
4. A Short History of Nearly Everything
I know I’m late in discovering this one (I’m always behind the times in my reading it seems), but what a gem. It’s a walk-through of, well, nearly everything in history. It is incredibly fun and kept me coming back for more with the clever writing and fascinating incites. It’s a great overview and refresher of everything you likely learned, and so many things you probably haven’t.
5. User Story Mapping
Going back to product management/product development, User Story Mapping is now one of my favorites. It is a great book on tools and techniques to use in building great products. I also had the opportunity to attend a session by Jeff Patton where he walked us through some of his key insights. If you ever get the chance to attend a workshop with him, don’t miss it. Worth every second. In the meantime though, you can definitely get a ton out of his book.
It was a great year of reading. I set a goal to read a book every 2 weeks, and I was able to do it! I’m planning on upping that goal for 2019, so hopefully I can keep up with an ambitious schedule and maybe even catch up with some of the current best-sellers (though that probably won’t happen).
Here is my full reading list as well (in order that I read them), including first time reads and re-reads:
Overall, it was another amazing year for our family. It's crazy to think that 2018 is over, but is fun to take a look back at how much we've accomplished and how much we've all grown. While I certainly wish a few things could have gone differently this year, I'm overjoyed with how well 2018 treated us. Here are some of the highlights:
Kelli and I were fortunate enough to take two vacations together this year. The first one was a relaxing and romantic getaway to Cabo. It was amazing to get out of the cold Utah weather for a few days and spend some time together just the two of us.
We also got to celebrate our 10 year anniversary in London! It was a dream vacation for Kelli, who has been wanting to visit their for quite some time. We had a packed itinerary, and walked a lot, but got to see almost all of our wish-list sites. It was an incredibly memorable way to celebrate the best 10 years of our lives.
Both McCoy and McKinley have grown immensely over this past year, and we're pretty much busier than ever with soccer, dance, art classes, swimming lessons, etc. I didn't realize how early this kind of craziness started, but we're in the think of it already with both of them. And it's great. It's been amazing to see how much they can learn and grow at such a young age. I was even able to start teaching McCoy to golf. We got a few rounds in during the fall and he is in love with it so far.
We were also able to finish our backyard, which was a monumental project and took way longer than I had hoped. It was hot and dusty and something that I don't want to have to do again, but the end result was worth it.
We were fortunate enough to be able to do a lot of family activities as well this year. It has certainly gotten easier with the kids a little older now and we've taken advantage of so many of the cool things close by.
I was also able to get my woodshop fully set up again this year, and despite being focused elsewhere for most of the year (that darn backyard), I still was able to get some great things done and had a great Christmas season on Etsy. My favorite thing was probably making a doll bed for Kinley and a corn hole set for McCoy. They turned out really well and Kelli did an amazing job sewing all the pieces to go with both. My hope is that doll bed gets to become something special for Kinley for the rest of her life.
This post could probably go on for quite a while still, but it truly was a great year, and it's hard to think of more we could have asked for. Here's to a 2019 that is even better!
When the only tool you have is a hammer, every problem tends to look like a nail.
A persistent problem I keep seeing is that some long-standing practices tend to take the place of better ways of doing things. I wrote about the example of product thinking and project thinking here, which is one way this happens. But so many other areas of product development are prone to this same problem. Rather than understanding the underlying issues and determining the best way to address, we can often fall into old habits or familiar thinking. Many times it’s not even a bad way of doing things. But we (and our organizations) can do better.
So how can we get out of some of our bad habits? How can we take our thinking to the next level?
Elevating Our Product Thinking
Understanding Problems over Gathering Requirements
The term “requirement” makes me cringe a little bit, and I try to avoid using it whenever discussing problems to be solved. The connotation of it implies a rigidity that simply doesn’t work for modern product development. And the way it has been used for years leads too many people to think of it as an order that is taken by the product manager or product team and incorporated into the product. It’s a requirement after all.
Gathering requirements has been happening for a long time, which is why it is such an ingrained way of doing things. But I’d argue that if you’re only gathering requirements and then prioritizing them, you’re missing most of the opportunities to build a great product and experience.
A requirement in this sense is really an initial idea or guess at a solution. And usually our initial guesses are wrong (sorry, but it’s true). That’s part of the reason I love the jobs-to-be-done framework (and one of my favorite books on the subject is Competing Against Luck). If you simply stop at gathering requirements, you haven’t gotten down to the actual job to be done — to understand the underlying need and if there is a better way of meeting that need.
To get to this level of understanding, we have to go beyond “gathering requirements” to truly understand users. A great way of doing this involves journey mapping and story mapping. (More to come on story mapping later, but if you haven’t already read User Story Mapping, go get it now. Absolutely a game changer.) As an example, we were recently going through the experience for a subset of users of our product. One request they had was a button to export data to Excel. If we would have stopped at that level, we would have missed the real need. As we dove into that request (or “requirement”), we found that the export was an intermediary step. The ultimate goal was to get the data into Salesforce. So what they really needed was to get information into a different system, not an export to Excel. These are the kinds of things we find as we really understand our users rather than simply take requirements.
Outcomes over Output
It is very easy to get caught up in the output. Output is easier to commit to and easier to measure. Delivering a feature is easy to understand. We committed to a feature, we built it, and now it’s out there. Done.
But this kind of thinking the creates poor experiences or features that no one uses. Rather than simply building features, we need to focus on the goals we’re trying to achieve. Building a feature is only part of that. We have to ensure that the feature helps us reach the goal. If it is meant to get more users, did it achieve that? If not, what is our next step to achieve the goal?
This is a major focus of our roadmaps, and what we’re trying to achieve with a good strategic roadmap. I wrote about this at length here, so I won’t belabor the point. But the focus should be on outcomes rather than outputs.
Value over Estimates
Along the same lines as the above, it is easy to get into a vicious cycle of estimation, sizing, etc. This seems to be intended to give comfort to teams and managers that everything has been estimated and will only take X weeks to complete. But the cycle gets worse as initial estimates are missed, forcing everyone to participate in more meetings to determine why the guesses were wrong and how can we make better guesses in the future. This, of course, leads to missing more timelines, creating more meetings, and on and on and on.
Do we really want our teams to be experts on guessing (if that’s even a thing)? Or do we want them to be experts on delivering value? Because we tend to put a lot of emphasis on one over the other. I’ve even heard it said that the mark of a good team is being able to give really accurate guesses. I’d argue the mark of a good team is being able to quickly and frequently deliver value to users.
I’ve found that this type of focus on estimates and timelines can actually be a substitute for delivering actual value. In my experience, nothing has quieted the calls for estimates and projections like delivering actual results. It’s certainly no silver bullet, but can help us make significant progress. So if we could take back a little bit of the time we’re committing to estimating and projecting, and use that to start to deliver small increments of value to users and stakeholders, maybe we can get out of the vicious cycle and focus on what we’re all trying to ultimately achieve: delivering value.
Shared Understanding over Comprehensive Documentation
In his book User Story Mapping, Jeff Patton gives some incredibly useful advice when it comes to documentation, particularly around requirements and user stories. First off, “You and everyone else will learn that stories aren’t a way to write better requirements, but a way to organize and have better conversations.” The purpose of stories isn’t to have some sort of complete documentation of the requirements on what to build (see above), but they are the starting point for the conversation.
The goal is to get to a shared understanding. Again from Jeff, “Stories get their name from how they should be used, not what should be written.” Most of us are probably familiar with the format of a story: As a [user] I want [a thing] so that I can [accomplish something great]. But it’s not about the format. It’s about the conversation.
It’s still far too common to think of handoffs between groups as the way of doing things. Siloing people into buckets/areas of responsibility that don’t cross over. The stakeholders give requirements. The product manager documents them. The team builds it. But that is how terrible software gets made. What we need is more collaboration between groups. The product manager should facilitate the understanding. The development team should be involved early on with stakeholders and users. The right solution is a joint effort, not a series of orders or handoffs down the line.
This goes not only for the stories, but also for acceptance criteria. Too often we look at acceptance criteria as the final word on what should be built. But the same theme applies. If acceptance criteria are created before a shared understanding, they’re likely to be wrong. What we need is team collaboration on what is being built. And that’s not to say that good acceptance criteria for features aren’t important — they are — but rather that they shouldn’t take the place of ongoing conversations and shared understanding.
Just-in-Time Refinement over a Comprehensive Backlog
Another concept I’d challenge is the idea that a team should have months of refined stories ready to pull into sprints, so that the next few months are planned and ready to go. Again, not that I’m opposed to the principle of planning and refining. I’m actually in favor of both of those things. But do we really know exactly what we should be working on in a few months? If we plan out all the details today, do we expect there will be no changes in 3 months? No learning that will take place between now and then?
A better way is to get continually more granular as we get closer. We can certainly have a plan for the next few months and next few releases. Even to the feature level. We should be looking ahead and understanding upcoming needs and priorities. But shifting focus from our current priority to the planned priority 3 months from now, and trying to get the same level of detail for both, is the wrong focus. We can’t, and shouldn’t, think that we can fully prepare stories and development work, then let it sit for a few months, and simply pick it up and begin coding when its turn comes. Rather, our energy is much better spent on the specific details of the very near-term, the broader details of the short-term, and the strategy of everything beyond that.
High-Integrity Commitments over Comprehensive Project Plans
All too often we fall back into the trap of putting dates on every possible feature and commitment from now to the end of the year (or other time period). The idea of a comprehensive project plan that will guide all our work and hold the team accountable is fraught with problems.
In one of my favorite product management books Inspired, Marty Cagan talks about high-integrity commitments. The idea being that we shouldn’t be putting dates on every single thing we do. Rather, we should only be making commitments to dates when it is necessary for a very good business reason. And when we commit to dates, it’s not a wild guess, but a well-researched and understood date that both sides can agree on. And we do this only when it is crucial. That way commitments to dates are meaningful.
Again, we put the focus on the outcome we want to achieve, not the output. And we don’t drive our teams to exhaustion with endless dates. We make and keep meaningful commitments. And they are meaningful because they are not the norm.
Real-World Experience over Textbook Simplicity
Finally, every approach needs to be modified for the context it’s being used in. There is a ton of great advice out there, and many great examples of how to do things well. But almost everything will need to be modified and adjusted for the world you’re working in. It is one thing to understand the principles and methods. It is another thing to appropriately apply them to the user cases and business problems you’re solving.
That is part of what makes product development and product management such an exciting and difficult thing. It is as much art as it is science. There isn’t necessarily one “right” way of doing things, as much as we may want to think that.
It is a balancing act. On one side there may be folks who say things like “that will never work here.” On the other side, there are folks who say things like “all you need to do is XYZ. It’s easy, I’ve done it before.” Be wary of either mindset. While we want to continually push for best practices, some of them need to be modified to fit. But that certainly doesn’t mean it can’t work here.
At the end of the day, the goal is to improve the lives of the users of our products. But we often can get caught in mindsets that keep us from achieving that goal as effectively as we might otherwise be able to. Often we have to get out of our comfort zone, and help others get out of theirs as well, in order to do great things.
My personal musings on a variety of topics.