At OpenSpace, I quickly realized we needed a better way to scale our decision making and ensure that teams and product managers were empowered to make the best decisions without getting slowed down by questions or unnecessary meetings or buy-in.

The main problem was that many of the decisions had long been centralized with a few executives and leaders. As the company grew, and as the product and engineering team grew, I saw that we needed a way to ensure that we could move fast without sacrificing on core principles that we all agreed on. 

But the key would be to agree on those key principles. First, as a product organization. Then as leadership and a broader company. So I led our team through several exercises (see the full presentation here) to determine where we were currently with our decisions, what we valued based on what we did, and where our most urgent problems were.

Once we identified the problems and tensions, we had a discussion about where those problems most frequently manifested themselves. 

This helped generate additional ideas from our group and got us thinking more about our product areas and the places where we would benefit most from guiding principles. 

From there, I asked everyone to take some additional time to write out the tensions they experienced, add any that they may have missed, and put those all on sticky notes so we could begin to decide what our principles should look like.

Once everyone had a chance to write down their ideas, we put them on the wall. We took some time to group similar ideas and ensure that we all understood the notes that had been posted. 

Once we had our groups, we plotted opposite ideas on continuums. I wanted to force us to pick a side. For example, should our product be very simple and targeted to new users? Or should it be very advanced and created for those who are experienced. While it may be possible to have a product that can do both, it is very difficult. And when we're making product decisions, it is much better to have a clear idea for everyone, if we're going to keep our experience very simple or if we're going to be the advanced software for professionals. 

With that in mind, we created about 16 continuums with the tensions we wrote down. From there, I asked everyone to vote on each continuum, placing a dot where they thought we should focus. If our product should lean all the way to one side or the other, or if they were more in the middle. This gave us a plot of how everyone felt about our product and the principles we were forming as you can see:

Once we had used our dots to vote, I led the team in a discussion about each of the continuums. I asked if anyone who had voted on either of the extremes wanted to give their opinion, especially in those cases when there wasn't a consensus or there was an outlier. This allowed us to begin to shape the overall principles as we discussed the thinking behind each continuum and the voting of the team.

I then took each of these and crafted our product principles and tenets. We used these with leadership to begin to get their input and acceptance in order to begin implementing the ideas as well as putting them into practice and testing them out.

I continued to update these principles as we got additional feedback, experimented with them, and revisited them periodically as a team.

For years as Western Governors University grew, it outsourced much of the technology it used to third parties. This made sense initially as it focused on education. But it became clear to the university that in order to scale, it would need to bring in-house the technology. Not only to better serve its students, but because it was a different education model. The technology of higher education no longer served its needs, and it wanted to not only create software it could use itself, but could offer to other institutions who wanted to offer competency-based learning.

With that in mind, WGU built out a product management organization, which I was among the first to come into and had the opportunity to help build and shape over my years there. 

In addition to building the product organization, I also had the opportunity to build out one of the key areas of the university: the assessment and evaluation software. For competency-based education, this is one of the most critical elements since testing knowledge is at the heart of competency.

I led several teams within the Evaluation Department, and had the opportunity to imagine, design, and build out from the beginning one of the key pieces of technology for evaluation management. We affectionately called it EMA, or the Evaluation Management Application. And while the experience for users , especially students, was designed to be seamless, EMA was a massive effort that was a flagship product for WGU in many ways. 

EMA was three applications in one. 

First, it was an assessment creation and publishing application. In order to have assessments available on the platform, we needed to create the ability for users, in this case faculty at WGU, to create and publish assessments to EMA. 

This was no small task though, since we had an entire department dedicated to developing assessments. So I had to work very closely with several teams to ensure we were creating the right tools to allow not only publishing, but different workflows for creating assessments.

We started out with very basic functionality as we began, and then grew and added layers to the capabilities that EMA offered to faculty. 

Second, we had the student-facing portion of the application. This was fully integrated into the student portal and was seamless for students so they didn't have to go anywhere outside of WGU to find or submit their tests. This was one of the most important parts of the application early on because we wanted the student experience to be incredibly simple and intuitive from the start, even if we had to do a lot in the background to make that happen.

Finally, we had the evaluation portion of the platform. This is where evaluators (a separate group of faculty) would come in to evaluate submitted exams, grade them, and send them back to students. 

Evaluation faculty was one of the largest faculty groups at WGU, and ensuring that we maximized their time was critical. When we began developing EMA, we started testing with just one exam, one class with 13 students, and a single evaluator. It was a good thing too, because we had to do a significant amount of work "behind the curtain" to make everything work and to learn, but with this learning we grew significantly over the subsequent months.

​There were numerous benefits to the development of EMA. We knew early on that no other solutions on the market were built for competency-based education. So we knew that building a platform specifically for this purpose would benefit our university, our faculty, our students, and the industry.

We also knew if we wanted to scale both as a university and help scale competency-based education, we needed to do this. We couldn't continue to linearly pay increasing costs as we grew. 

This was one of the key pieces of analysis I did early on. Because we had many stakeholders who were very skeptical of the need to create development teams, dedicate significant resources, and ultimately own internally all of this technology. Finance was chief among the skeptics. So I worked on initial analysis and then ongoing updates to show our progress.

We developed EMA iteratively, as I mentioned before. We started out with a few students, a single evaluator, and manually doing much of the work behind the scenes to test out a lot of the processes and to make it work without doing too much development too early.

We then got more colleges involved, more departments, more students, and more evaluators. And the complexity scaled significantly as we grew.

I could dive into many stories of lessons learned and issues we had to overcome, but I'll touch on just a few here. 

Early on, we made the decision to build using a Cassandra database. Cassandra is a non-relational database. It is good for many things, and good if you have the expertise to maintain it. This was an architectural decision we made based on the expertise we had at the university, but turned out to be a mistake. A non-relational database was not right for our purposes, and our Cassandra expert soon left, leaving us without the necessary expertise to properly maintain the database.

As we grew and scaled, we began to notice performance issues. As records were being deleted, it left a "tombstone". We didn't realize that we needed to clean up these tombstones in the database, which led to further problems. We also were part of a broader organizational effort to migrate to AWS.

Given our lack of team expertise in non-relational databases, the need to move to AWS, the desire to better manage our application and database with a relational database, we decided that before we fully scaled up, we should move from Cassandra to Aurora on AWS. This meant a re-write of most of our application and a full migration.

We had to pause all of our feature development work. I led the team on discovery to flesh out the details and estimate the scope of work, as well as worked with stakeholders to help everyone understand the need for the architectural changes and the benefits once they were done.

We estimated, created the plan for work, and began. As with all projects, it took longer than our optimistic plan, but aligned with our conservative plan (or maybe with Hofstadter's Law), but we completed the move to AWS and our move to an Aurora database.

Additionally, we created a seamless user experience for faculty and students. Students no longer had to submit their exams through an outside portal or vendor, but could access everything within the WGU student portal.

For faculty, we created a more seamless interface that worked the way that they worked. Rather than forcing them to conform to an application, we created an application and platform that worked with them, helping them save time and mental energy, getting them through their work more quickly.

The rollout and launch of EMA to all of WGU was a multi-phased process. It involved working with every department at the university in some way, given that it touched everyone at some point. 

I initially had to determine which courses and programs made the most sense to focus on initially. And from there, determine how to get those assessments, students and faculty onto our platform. This involved incredible buy-in from across the university, especially as the number of courses, students, and faculty grew.

I faced competing pressures as we built and launched. There was the pressure to move quickly, get our new platform out, and start to realize the savings and the UX benefits. But we also had to balance that against the changes we were asking everyone to make, especially to longstanding processes that were not easy to adjust. While we love to move quickly in technology, that isn't the case in other disciplines or departments, and we have to be conscious of that.

I had to work closely with many groups, and we made lots of adjustments to our timelines and rollouts as we went.

As Teem was acquired first by iOffice and then by SIQ, it was critical we establish a cohesive product vision and strategy to define Teem's positioning amid the market, competitors, and the portfolio of companies within our organization. So I created an analysis of user and market needs, Teem's positioning, and a vision and strategy for our product going forward. 

I worked closely with other members of our product, design, marketing, and engineering teams, and then presented and socialized this information more broadly to continue to gain support and help others both add to it and understand the direction we were looking to take Teem and the product. 

First, it was important for us to understand the market and the context for our company and our product, especially as we were coming out of the pandemic and more companies and employees were returning to the office in some way. 

Next, I focused on our users, their key needs in the immediate-term as well as the longer-term. It was important for us to consider the current situation, which was Covid-19 and a gradual return to offices, but also the longer-term situation which would likely see a complete mix of remote, hybrid, and in-office depending on the needs of the company and the employees. 

I also looked at the history of Teem, its place in the market, and its competition both directly as well as from other incoming solutions. 

Teem was built from employee experience first and then moved toward administrative tools. Unlike other competitors expanding in desk and room booking, Teem was built for the user in mind and was easier and more intuitive to use than other offerings on the market. ​

This was an important consideration because Teem was moving more into administrative tools while companies that started out more focused on admins were moving more into the employee experience. 

Finally, I reviewed the challenges that Teem was facing from a company standpoint, a product standpoint, and a market standpoint. 

Once we had thoroughly reviewed the the market, our users, our competitors, and our company, I crafted a product vision that could address the key needs of users, utilize our strengths as a company and positioning in the market, and focus our efforts on creating the most important products, features, and experiences for the new work environment.

In addition to the product vision, I also helped craft our product positioning. This was an important aspect given that we were part of a larger group of companies within a private equity portfolio and wanted to focus on the correct positioning within that group of companies and within the broader market. 

Finally, in order to achieve the vision, I crafted a product and company strategy that could begin to guide us in our prioritization of existing and new product development. We needed to focus our efforts on the right things in the right way, and this was the strategy for that.

With a vision and strategy in place, as well as an understanding of our positioning, we were able to really focus our development efforts and prioritize new features and products correctly. This was the beginning of a much firmer and better direction for Teem. 

At Clearlink, our product organization worked closely not only with the broader organization, but also worked closely with marketing partners in order to build new products, test ideas, and drive better business outcomes.

As part of this, we were often running A/B tests of marketing changes. We worked with our partners to create new marketing copy and then test out the changes over certain periods of time to see what images or phrases would work best for their sites.

But as I helped build out the product and UX organization, we wanted to expand from just running A/B tests on copy and images and use the same methodologies to experiment with user flows and the actual experience of the users on the sites.

This was a bigger deal, both for our partners and for our teams because it involved more work to create the changes, as well as more buy-in to allow us to run experiments not just with language or images, but with the actual experience of users. 

But we were adamant we could improve the user experience of their sites, helping to improve traffic and drive additional conversions. So we designed and created a new user flow for one of the sites that we targeted first. This was an online retail site that gathered information and then moved people to either sign up online or call a number to sign up.

Our hypothesis was that we could simplify the user flow, eliminating over two-thirds of the steps to get the user from first action to a purchasing decision, and increase conversions by requiring less of the potential customers.

I worked closely with our partner to overcome a number of obstacles and concerns, and we created prototypes, reviewed designs, and prepared stakeholders for the changes we were creating.

​(This may seem like overkill for some good UX changes, but we were dealing with a large telecommunications company that didn't like change and didn't like to move fast or try new things, hence the need to really get everyone on board)

We ran a 2 week test of our changes versus the unchanged site. We randomly assigned visitors to one of the two sites, but also tracked unique users and attempted to give them the same experience if left and returned.

This specific site traditionally got thousands of visitors over the timeframe we were targeting, so we were confident in getting enough traffic for a meaningful result.

We used many of the same targets for other A/B tests that we ran for other marketing purposes, including a full testing period and appropriate confidence intervals to test for statistical significance. 

It's important to run a test for a full length of time, because stopping a test short can lead to noisy results or incorrect conclusions. This was certainly a temptation, especially with a partner who had reservations about so many changes and also would want to stop using one of the sites as quickly as possible if the other was showing significant good results comparatively.

​As you can see from this image, there is noise in data, and stopping an A/B test early can lead to making the wrong decision, which is something we reminded everyone of as we tested.

The results of our UX changes were even better than we expected. We had set a p-value of 0.05, but got a p-value of 0.01, suggesting statistical significance beyond random chance as we saw conversions almost double over the time period on our site with the UX enhancements versus the original site.

This was a validation not only of the changes we made, the designs we created, and the work we did to get the partner on board with the test, but also more broadly validated the work I was doing within the product and UX organization. UX changes--designing better experiences and not just nicer pictures or better wording--has a significant impact on the overall user experience and ultimately the business value. 

I continued to use this as an example of the value of product and UX as we worked internally as well as with other partners, to help everyone understand how and why we can focus on the users and why taking time to design the whole experience adds significant value.

I believe wholeheartedly in the power of quantitative and qualitative data. I often view it as a funnel where quantitative data and point us to issues or opportunities, and qualitative data helps us dive deeper in order to create compelling solutions.

Once HealthEquity HSA members have saved a certain amount of money in their health savings accounts, they can invest the additional or excess funds from their HSA in a variety of mutual funds. As a product team, we knew from our analytics that a significant number of users didn't complete the investment onboarding and that we needed to fix this to grow our investment users and help all members maximize the benefits of their HSA.

I used qualitative and quantitative data to create a significantly better investment onboarding experience at HealthEquity.

When I came into the role, we knew that the investment experience was clunky and outdated. But didn’t know much beyond that. The company wanted to make it better, but didn’t know where to focus, hence my role.

I started by analyzing the user flow from the instrumentation we had (which thankfully, was pretty good). I noticed a couple things, like a 50% drop of at one point in the onboarding process, and another point where around 3/4 of the users who made it there fell out.

That gave me great context for diving deeper. I started by watching actual users go through the investment onboarding flow without interfering at all. I wanted see and understand the process from their point of view.

Like the data showed, there were drop-offs at a choice between several investment options, another at the selection of investments, and finally toward the end before completing.

So I started to ask “why”. After a series of interviews, I had a much better understanding of the problems user were facing. This included being overwhelmed by the choices, unfamiliarity with investing, or just fear of pulling the trigger.

But I didn’t stop there. With that understanding, I worked with our UX team to create new user flows. We mocked them up and I put them all into Invision so we could test them with users.

I went out and spent several days onsite with customers having them walk through our mockups. We learned that we had made the process better, but still hadn’t solved all the issues. One key problem was that we presented users with too many choices too early. Specifically, we asked them to pick between three options for investment guidance right at the beginning: Auto Pilot, GPS, or Self Driven investment. 

This required buy-in from a number of groups, including our investment team, sales, marketing, etc.
​
So I made the pitch and showed them the data from our current users as well as the feedback from interviews. This helped everyone understand the need for pricing changes and a simplified process. And we moved forward with it, doing a few more testing sessions and then releasing the first iteration.

We moved to simplify to investment flow as shown below. Rather than multiple screens and steps, we consolidated the decisions and guided users along the right path.

Amazingly, in 2008, not even that long ago, Myspace was the top social network platform. While Facebook was rapidly making progress, Twitter was still in its early days, and Instagram, Snapchat and TikTok were still just gleams in the eyes of their founders, Myspace was the place to go.

So what happened?

Like any story, it’s complex. But one key issue was a lack of product focus. Myspace didn’t know what it wanted to be. You can see that in the image above. Was it a place for friends? A place for music? A place for games or videos? It ended up being a place for everything, and it did none of it well.

Myspace didn’t have an obvious idea of what it wanted to be or accomplish, and could never decide on the best way to get there. That’s not surprising. If you don’t know where you’re going, it’s hard to figure out the best path. And within a few years, Facebook dominated social media. Which should never have happened. When you have an existing network, maintaining it should be the simple part. But they weren’t able to do that.

And the rest is history.

So how can we avoid becoming Myspace? The secret (or not-so-secret) ingredient is to define clearly what you are trying to do — within your company and within your product. Myspace didn’t fail for lack of experimenting, but for lack of clearly defining what they needed to do to be successful and then executing well on those things.

A great tool for avoiding this issue is OKRs. I’ve used OKRs in almost every team I’ve been in. There isn’t anything magical about an OKR itself, but the principles and the process make them extremely successful. So let’s take a closer look.

A Little OKR History
For those unfamiliar, OKR stands for Objective and Key Result. The objective is a high-level, aspirational goal you are trying to achieve, and the key results are how you are going to measure your success. That’s it. They are meant to be collaborative, open, and transparent. They are also meant to push you, your team, and your organization. So they’re not necessarily a good fit for every situation, but more on that soon.

We consider Andy Grove the father of the OKR. He created them at Intel in response to the more limited goal management styles that existed at the time, such as MBOs (management by objective) and KPIs (key performance indicators).

MBOs were centrally planned and trickled down the hierarchy. Unfortunately, that may still sound familiar. And Grove considered KPIs numbers without a soul. While we still like KPIs in the right context, you can’t push yourself with KPIs alone.

Why use OKRs?
If you read Measure What Matters, you’ll become familiar with the four OKR superpowers: focus, align, track, and stretch.

Focus
The most important feature of an OKR is that it allows you to focus on the most important work. It explicitly calls out what you are focusing on, and by its nature, what you are not focusing on.

This is powerful for teams and organizations. You shouldn’t have a laundry list of OKRs. Just like you can’t prioritize every product feature as the most important, you can’t prioritize every initiative or every goal as the most important. You need to focus.
​
Steve Jobs famously said, “innovation means saying no to one thousand things.” And he meant it. When he returned to Apple from his time in the wilderness, he cut their product line down significantly. He focused the company so they could deliver fewer things, but better products as shown below.

This became very salient for one of my teams. We had a long list of priorities and had been reordering it for a while. As I introduced the OKR framework, I asked the team to focus on one thing. What was the most important thing to accomplish? It was a change in thinking for many. They were used to changing priorities according to the loudest voice, which would happen every few weeks. We eventually agreed on a key outcome to focus on for the quarter. We’d prioritize all the work around that and deliver.

It was difficult in the beginning. I had to remind everyone of our focus, both on the team and outside. But the outcomes were outstanding. Rather than incremental changes over long periods of time, we delivered meaningful change in a quarter. Once the broader organization saw what that kind of focus could do, it wasn’t so hard to sell everyone on the idea from then on.

Align
OKRs are a tool for empowerment and alignment across a team and organization. Remember the MBOs above? Executives would create objectives and hand them down to employees, who would then be accountable for parts of them. You can probably see multiple problems with that.

OKRs are a top-down and bottom-up process. Yes, executives and leaders should have OKRs if your company is using them. And you should be able to see their OKRs. You and your team should also have OKRs, and everyone should see them as well. The purpose is to allow everyone to see what everyone else is working on so we can align up and down and laterally.

We talk a lot about the up and down part, but not nearly enough about the lateral alignment. If other product teams have OKRs or goals that impact my group (or vice versa), it’s important we’re aware! Or if marketing or sales have specific objectives that are going to take some work from product and engineering, we should probably collaborate on that!

If this sounds like a messy process, you’re right. It is highly collaborative and hands-on. Teams will often spend lots of time working on their goals and objectives, but we need to spend a meaningful amount of time working across groups to align on goals and results.

Track
If you’ve ever been part of an annual planning process, you’re probably familiar with the weeks or months that go into putting together detailed plans, the meetings and discussions and presentations, and the agonizing over budgets and details. And after it’s all done, everyone quietly puts those plans away for the year until it’s time to revisit them next year.

That’s not how OKRs work. It’s probably not how annual planning is meant to work either. We use OKRs to track our progress continuously. And to hold us accountable.

I use a Fitbit along with some other health tracking apps. I like to monitor my progress and set goals for myself. I check in regularly with my progress so I can course correct (most often) or celebrate (less often).

The same idea applies to OKRs. If you set an OKR at the beginning of a quarter and check in at the end of the quarter, you’ve done it wrong. It’s a good start, but by that time there is nothing you can do. The tracking is best done weekly, checking your progress so you can make actual corrections and take action to achieve your goals by the end of the quarter (or time period). Hopefully, it will also give you a reason to celebrate throughout the quarter.

Stretch
Finally, we use OKRs to stretch. Don’t use an OKR for something like “keep satisfaction above 90%”. If you’re happy with where you are, that’s not a place for an OKR (more on that later). OKRs should push us, our teams, and our companies to higher heights. If it’s easy, and not without a chance of failure, we’re not stretching enough and it’s not an OKR.

I recall an OKR meeting we had where one team laid out their proposed OKRs for the quarter. They sounded reasonable, but nothing about them seemed out of reach. We were still early in the OKR process, and it sounded like the team had taken the work they had planned to do, put it into an OKR format, and was content.

It’s not enough to set OKRs for what we know we can do. We need to push ourselves, our teams, and our organizations.

Who should use OKRs?
You should. Your team should. Your organization should.

Every product team I’ve come into hasn’t been using OKRs. Neither has the organization. But you don’t need the entire company to start. I’ve always started with my product teams and product organizations, and the company has come along after.

You should start using OKRs wherever you are. If that means starting with yourself, great. What do you want to accomplish? How will you know when you’re successful?

If you’re a product manager, create OKRs with your product team. One of the biggest changes I’ve made on every product team (and product organization) is to incorporate OKRs into the process. What do we want to accomplish as a group? How will we know we’re successful? How will that help our company and how can we show it? This will change the conversation for you and your team. It elevates the discussion from the features you’re building to the outcomes you’re driving. And the glorious thing is that you don’t need anyone else to even be using OKRs. Others will see your success and want to adopt them, but you can start right now.

Your company should also use OKRs. This one may be out of your control if your company isn’t currently using OKRs, but I’ve helped organizations start using OKRs after introducing them to my teams. And I’ve pushed for them in other places, even when they haven’t been implemented.

OKRs may not be the end-all, be-all solution, but they are powerful tools for individuals, teams and companies. And in every situation I’ve seen, groups will be better off using them than not.

When to use OKRs?I always start with annual OKRs, or at least annual strategic initiatives and objectives for my teams or organizations or products. It helps me think about the bigger picture of what I’m trying to accomplish and what success will look like as we build up over the course of the year. That’s not to say that I’m married to any specific plan, but it helps to visualize where we’re going. I also tie them up to company level goals or initiatives to ensure that I’m aligned with where my company is going and what we’re focused on.
​
From there, I break down quarterly objectives and key results. Quarterly OKRs are pretty standard, since it is a long enough timeframe to get work done, but also short enough to make course corrections as needed.

Besides annual and quarterly OKRs, it makes sense to focus OKRs on product areas that will benefit the most. I’ve alluded to this above, but not every product or initiative will benefit equally from an OKR.
​
In a discussion at a conference, Christina Wodtke gave a splendid example of when to use OKRs based on types of products and where they fit into a BCG matrix. For high growth products, it makes sense to use OKRs to push yourself further with them. But for products that are in maintenance mode, either because you are sun-setting them (dogs) or because they are simply cash cows and you are going to continue to let them do their thing but you don’t expect to grow them, the better course is to monitor them with KPIs.

​How to use OKRs?
Shift To Outcomes
Rather than starting with what you want to do, start with what you want to accomplish. Stop talking about features and start talking about outcomes.

On my teams, I always try to shift the conversation away from features to the outcomes we want to achieve. Features are the means by which we get there, but a feature may be effective or it may not. We can’t be married to any particular feature. We have to love the problem and the goal, and find a way to achieve it. We also need the flexibility and the space to achieve that goal.

This can be a mindset shift for many organizations. I refer to it as product thinking or a product mindset. And it can often take time. Many companies are more accustomed to focusing on a list of features or projects for each team. And possibly setting goals based on that. But that is backwards.

I’ve gone through this many times with teams. You may be familiar with it as well. If you start with features or projects, you’re coming at it backwards. You need to start with the objectives. Start with the OKRs!

Quarterly OKRs
Once you’ve shifted to an OKR style of planning, you must actually implement it. Quarterly OKRs are the most common. If the entire company is starting, it will usually start with leadership teams or department heads and move down. If you are starting with your group, well, it starts with you!

Don’t expect it to be easy or smooth. OKRs are difficult and take time. You need to put in time and thought before, and then expect debate and discussion. You should set aside several hours initially for all of this. If you have a large group with lots of OKRs, you may need more. Don’t skip past the discussion and debate. It’s important in shaping the best OKRs. You want to create good goals and good measurements that you and your team can get behind, so take the time to do it right.

Regular Cadence
In her book, Radical Focus, Christina Wodtke gave the simple matrix below to show how to implement OKRs effectively into your weekly cadence.

Each Monday you should review your OKRs (the fewer, the better) and how things are progressing. You should check in on your priorities for the week in order to achieve your goals with your objective, and anything you need to do in the next month. And your health check are the KPIs or metrics that you don’t want to let slip as you reach toward your bigger goals.

The key is to make the check-in part of your weekly cadence. Start Monday with what needs to be done and end Friday with how things went. It is critical to success, and harder than it seems.

​Common OKR mistakes
Too many OKRs or key results
I recall one leadership meeting I narrowed my OKRs down to three. I had more critical things I wanted to focus on, but more than that would be too many things to focus on in my opinion.

OKRs were new to the company though, and not everyone shared my opinion. So some leaders came in with eight or nine OKRs. And we debated. Everything they had on their list was important. And I left some important things off of mine. Who was right?

I didn’t budge. I knew if I added more than three objectives I’d take too much focus away from what was important. And I wanted my team to focus. Fortunately, we agreed focus was more important than including everything, though I still think that some lists remained too long.

If you have too many objectives or key results, you can’t focus on what is important. The fewer objectives and key results you have, the better you focus on what is important. The more you and your team can rally around the goal. And you can more easily say no to things that distract you from your mission.

If everything is an OKR, nothing is.

Tasks as key results
Another mistake I’ve seen frequently is making your task list into your key results.

For me, this results from having an output as an objective rather than an outcome. In one example, the objective was something like “replace all the old phones”. Then the key results were a list of milestones like “order new phones”, “replace phones in area one”, “replace phones in area two”, etc.

Your OKR shouldn’t be a task list. It shouldn’t be a maintenance item. OKRs are about driving meaningful change for your business and your users. Why are you replacing phones? What impact should it have? How can you measure it? And if you don’t have a good way of measuring it, should you find one? Lots of areas need better measurements, and OKRs can be a good way of shedding light on that. And if that’s not the case, should you be using an OKR here at all?

Never reviewing
It’s so easy to set goals and never review them. We create a plan and then never revisit it. We simply hope for the best.

OKRs are meant to help us track our progress. And not just quarter to quarter, though that is an improvement over the annual planning process. We should track progress continually. We talked about it above. Including OKRs in our weekly planning process is critical to their success.

I’ve found the most success including OKR status checks into existing team meetings. If you are part of a scrum team, you likely have bi-weekly meetings at the beginning and ending of sprints. Those are excellent times to review sprint goals and OKR statuses.

If you are part of a larger team, you probably have some weekly meeting or bi-weekly (fortnightly) meeting. Add OKR status reviews to those meetings. Check progress and see how things are going.

Trying to copy XYZ company
No two companies are the same. I’ve used OKRs at multiple companies now and every company does them differently. Google does them in Google’s own style. You don’t need to be Google. Be your own company. Find your rhythm.

You will flounder for a bit. But you will find the style unique to your organization. Learn from the books and articles and things that others have done. Learn from others who have used OKRs in other places. And then take all of that and don’t feel bad for not being perfect. That’s not to say you shouldn’t try to be good at OKRs or use good principles, but you don’t need to be Google or Intel.

OKRs aren’t a silver bullet, but they are a great tool to empower teams and change the mindset of your organization. Rather than focusing on features, they help you focus on the outcomes you want to achieve, and empower the groups and organizations to achieve those outcomes. They take some practice, and will require giving up some centralized control, but the results will be better outcomes for your business, your users, and your employees.

In The Hitchhiker’s Guide to the Galaxy, one of the strangest and arguably coolest phenomenons is the Babel fish. It is a small, yellow fish you place in your ear that feeds on your unconscious mental frequencies. In return, it then excretes back into your mind a telepathic matrix from the conscious thought frequencies and the speech centers of the brain. Basically, all of this allows you to understand instantly anything said to you in any language. Which comes in handy when traveling the universe and encountering many civilizations speaking unfamiliar languages.

While we’re not necessarily traveling across the galaxy or running from Vogons, our businesses still need the equivalent of this translation and coordination: a mechanism to ensure that all the various groups and disciplines within our organization are speaking and understanding each other. And that we are hearing and understanding the outside voices of our users, customers and industry.

That is the essence of product management. To ensure understanding across groups. To coordinate. To solve real problems.

How do we accomplish this? How do we gain this understanding, coordinate, and translate across teams and across our company? Product managers do this by focusing on 5 key areas:

1. Discovery & Research
2. Strategy & Roadmaps
3. Partnership & Communication
4. Prioritization & Tradeoffs
5. Delivery, Launch & Go-To-Market

Discovery & Research
Product management begins with understanding. And that is what product discovery and research are — the ongoing practice of understanding user needs, business needs, and market trends to decide what to build.

For a brief history, back when software was still being packaged into CDs or DVDs and being shipped to stores, product discovery and research looked very different. Much of the research and discovery was done upfront out of necessity. If you were a product manager, you had to figure out what would get built and go onto the DVD before it shipped.

Unfortunately, many of these practices have never gone away, even though we don’t package most software into a box any more. The idea of gathering long lists of requirements up front, passing them to engineering teams, building large projects, and then hoping that it all works out once it gets to customers.

Good product managers should not be gathering long lists of requirements for modern software, though. Or passing lists off to development teams. Or waiting for feedback from users. The miracle of modern software is that all of this can and should be done in the shortest increments possible. We should work constantly on understanding users, our business, and our markets, continuously adding to our dataset to make better decisions. We should work closely with our development teams so we all have a shared understanding, rather than “toss over the wall” lists of specs. And we should get regular feedback from users and stakeholders. Monthly, weekly, daily. As frequently as you can so you can add that knowledge to the dataset you’re building.

Discovery and research may often feel like it is easy to put to the side. As I’ve worked with a variety of product teams, I’ve seen how easy it is to dedicate far more time to execution and delivery than to research and discovery. Often product managers will look at their impossibly busy schedules and feel forced to make that tradeoff. Getting things out the door always feels more urgent than building an understanding of markets and users. But that is trading the long-term for the short-term. The best product teams and product managers find the right balance, investing in the future while delivering in the present.

For a deeper dive, see my upcoming article Product Discovery: The Beginning of Good Product Development.

Strategy & Roadmaps
Once product managers have done discovery and research, understanding their users, their business and their industry, their role is to set the strategy and roadmap for their product.

Strategy
The product strategy should align with the higher product vision of the product organization. We won’t get too much into that here, but this vision should be compelling and long-term (think 3–5 years). And the strategy of each product should support it. Your product strategy also needs to align with broader business goals and strategy.

As a product manager, it is your job to set the product strategy for your product, together with your product leadership. We’ll talk more about this below, but you shouldn’t be looking to executives or stakeholders to do this for you. You will need their input, and depending on your company, you may have to balance stronger opinions with your own, but working with your product leader you should create the strategy.

Think of the strategy as a way of achieving the vision, so 1–2 years in horizon. It is fundamentally about how you’re going to achieve the goal of your product, whether that is 10Xing the business or doubling revenue.

One of my favorite tools to solidify the strategy for a product is to use a future press release. This is a tool made popular by Amazon and written about by many others. I’ve used it myself with splendid success. More on that in another article to come soon.

Roadmap
From the strategy, you should create a strategic roadmap, which tells the story of how and why you are working toward the long-term strategy of your product.

Roadmaps are not feature lists. They discuss ideas and direction, so features may be part of that, but the focus should be on the outcomes you’re trying to achieve and how the features may get you there, not on a list of features. Roadmaps also are not timelines or project plans. They are meant to give the direction, but we’re not ready to commit to specific dates or items because we’re determining what will get us to our strategic outcomes.

So if that’s the case, what should be the focus? Roadmaps should be about inspiring participants, communicating the strategy, generating discussion and gaining alignment. The focus should be on the outcome you’re trying to achieve with your product, how you intend to get there, and why that’s important.

For more thoughts on roadmaps, you can see my article on Product Roadmaps: Love, Hate (& Hate).

Partnership & Communication
Product managers are essential in partnerships and communication across an organization.

Communication is literally one of the top traits of a good product manager, so this should be no surprise that it is a key role. But product managers are uniquely positioned to facilitate partnerships and communication both within a department, a company, and outside an organization.

First, the very nature of the role is one of coordination within a product development team and across stakeholders and customers. So you should be building relationships and communicating relentlessly. This starts with your vision, strategy and roadmap, as we discussed above, and continues with prioritization, tradeoffs and delivery as we’ll discuss below.

Second, your role is to create the best product experience for your users and to deliver value through that for your business. You can’t do that alone. You literally need your users and your business partners as part of that equation. So partnering with them, building the relationships you need, and communicating frequently are all critical parts of the role of product managers.

Finally, you need to be an excellent partner and listener. It’s not enough to go out and evangelize your product. You also need to hear and understand your users and stakeholders. That’s the other side of partnership and communication. Don’t forget it.

Prioritization & Tradeoffs
One of the most troublesome parts of product management is prioritization. Frankly, it’s one of the most troublesome parts of life. Because we often have to choose between many good options and make tradeoffs with incomplete information. But it is a critical part of the role.

Prioritization is much more than just choosing the order of the backlog though, or what feature to work on first, though those are important aspects. For a deeper dive, see my article Prioritization: Choosing is the Hardest Part.

At a high level, prioritization comprises:

1. Establishing a vision and strategy
2. Understanding the context
3. Gathering inputs (qualitative and quantitative)
4. Ranking your priorities using any number of frameworks and gut checking your assumptions
5. Deciding on priority
6. Aligning and realigning

Like I said, prioritizing features on your roadmap is only one part of the bigger picture. There are a number of frameworks and methods for doing that, all of which have good attributes, so it will often depend on your company and context which will work best. I’ve used many as a product manager and product leader, and as long as you don’t outsource your prioritization to a framework since that doesn’t work, you’ll be fine. Remember, they are tools, not solutions.

Also, you are responsible for gathering the inputs and translating that to action. Stakeholders from marketing will have one perspective. The engineering department will have another. Sales will have yet another. None of them are wrong and all will be urgent and important. Everyone will need to understand the inputs, the framework for deciding, and why we’re prioritizing the way we are (see communication above). It will not be easy. Hopefully, you didn’t think it would be.

Delivery, Launch & Go-To-Market
Finally, everything above will be for naught if you don’t get your product to market and into the hands of users.

Depending on your company, delivery, launch and go-to-market may fall squarely on the shoulders of the product manager. Or it may be a shared responsibility with other groups like project managers or product marketers or sales or other groups. Regardless, it is your product, and you need to get it to your users. So it is your responsibility, no matter who else is helping or sharing in the burden.

After so much work to do discovery and research, create a compelling strategy and vision, partner with stakeholders and users, and make the necessary tradeoffs, it is almost tragic how often I’ve seen teams falter at the finish line. Don’t drop the baton at launch! Make sure you put as much time in preparing a successful launch and go-to-market strategy as you have put in preparing a great product or feature.

I’ve learned this lesson the hard way myself. Several years ago, as we created a new experience in a product we were building, we were incredibly excited about how much more intuitive it was and how great it would be for users. But when we launched it, it fell flat. We had failed to involve our support team and our training teams (we thought we wouldn’t need them since it was so good), but our users were not prepared for any changes. So we had to step back, get training in place, and then move forward again. What should have been a big step forward was delayed because we faltered with our launch strategy. I didn’t let that happen ever again.

While not exactly Babel fish (and we’ll leave the theological arguments aside, and whether product managers will eventually cause more wars than anything in the history of creation — see The Guide for more), product managers are the key to unlocking and translating real problems into real opportunities for our businesses and our users.

According to Captain Kirk, “Intuition, however illogical, is recognized as a command prerogative.” Would Spock call that illogical? Maybe. But that is part of what made Kirk and Spock such a great duo throughout the Star Trek series and movies. There is logic and emotion tied to what they do, with both of them representing either side, sometimes to an extreme, and other times surprising us.

But that is often what they needed to make their missions successful. Quick, emotional decisions vs. deliberate, thoughtful action. The push and pull.

Product managers and UX designers make up two of the three key members of a product team leadership trifecta (the other member being a technical lead). Most times, the overlap between the UX designer and the product manager will be significantly higher than with the technical lead or engineer, so finding the right balance in the relationship is critical. We talk about this in a recent podcast episode you can find here.

With that in mind, what can we do to better support each other, deal with issues, and ultimately build the best products and user experiences for our businesses and our customers? How can we create the right push and pull?

The Ideal Structure
Ideally each product, user experience, or vertical (depending on the size and focus) would have a dedicated product manager and UX designer. For larger companies or products, we could break this down to smaller components where product managers and UX designers focus on large features within the product, but the concept is the same.

This allows the right level of focus on identifying the right problems to solve, the right ways to solve them, and the right business opportunities to pursue from a product perspective.

Dealing With Less-Than-Perfect Scenarios
Unfortunately, we have to play with the cards we’re dealt. And often we don’t get to have a dedicated product manager or UX designer for every opportunity, customer journey, or even product.

You’ve probably been there. You may be there right now. As a product manager, you may not have a dedicated UX designer for your team. I’ve experienced that scenario throughout my career as organizations are usually slower to adopt user experience design as a formal practice. Even now as I’m building up the UX team at our company, we have more product managers than designers and likely will for a while.

Here, it’s critical for product managers, and everyone on the product team, to step up and own as much of the UX as possible, filling in gaps and extending the abilities of the designers wherever possible. The ultimate goal is to infuse design thinking into everything we do, so this is a step along the way, albeit without all the necessary support, but since we’re designing a user experience regardless of whether it’s intentional, we might as well be thoughtful and deliberate about it.

In an even more extreme scenario, a team may not have a dedicated product manager or product designer. While someone will fill those roles, it is critical to the success of the product, the success of the user, and the success of the company to dedicate the right mind share and the right people to those tasks. Product management and UX design are not part-time jobs for anyone. Helping leaders see that and understand the value so we can move toward more ideal scenarios is key.

Combining Forces
Regardless of the structure, whether ideal or less-than-ideal, the best user experiences and business value come from combining forces. Like joining our powers and using our planeteer rings to summon Captain Planet (you’ll have to look it up if you missed the Captain Planet cartoons of the early 90s), we can create incredible things through a focused, joint effort.

Generally, product managers bring expertise in valuation, prioritization, and business process. Product managers should be well-versed in all aspects of their product, their industry, their users, and their business, but most product managers are especially adept at wrangling the business and user problems and finding solutions and value. It’s the core of product management and why many of them are doing what they are doing.

UX designers bring a different, and much needed, perspective to product development. By focusing more on the user experience, they ensure that the product isn’t just solving a problem, but is doing it in a desirable way. UX designers come into the craft from a variety of backgrounds, but their focus on the overarching user experience, the interaction, the visual design, makes the product not only functional, but appealing.

None of this is to say that product managers don’t want appealing products or that UX designers aren’t focused on business needs, but product managers and UX designers tend to have differing areas of expertise, slightly different focuses, and different perspectives.

This push and pull within the product makes it great. If you focused solely on making a product valuable to the business, it may be profitable but it would likely be a terrible product. And if you focused solely on making a product visually appealing and a great experience for users, it would be an excellent product, but may not be valuable at all for the business. So we need to combine forces, find the balance, and create the right dynamic to create excellent experiences.

Better Collaboration
UX Designers Supporting Product Managers
How can UX designers better support product managers? We all operate under significant constraints. Almost no product manager wants to go to market with a crappy product or a crappy UX, but often there are tradeoffs that they are considering within the business, for stakeholders, and for users. So understanding those constraints is useful in better supporting product managers as a UX designer.

Product managers are often under technical, business, and time constraints, among many others. And while none of those are excuses to cut corners, we often have to made a tradeoff in one place to gain ground in another, at least for a time. Without the full picture, that may appear equivalent to shoddy work, but context is key, which is why understanding the scope and building trust is paramount.

When I was working as a product manager on a key product for our company, we fortunately had a UX designer that embodied these ideas. She understood the business and its needs. She had a good grasp of the technology. And she understood many of the time limitations we were often under. So when I came to her on a particular urgent request, we didn’t have to do the rounds. She was able to help the development team with designs and user flows that satisfied an urgent business need that they got to work on quickly.

Product Managers Supporting UX Designers
For product managers, you need to trust your UX designers. Trust that they have good reason for the choices they are making and have the data and research to back it up.

Product managers are naturally very opinionated, especially about their products. Whether it is the language on a page or the placement of a button, the PM will have an opinion. But a talented designer will do you one better. She will have the research to tell you why the language should be a certain way or the button placement should be in a certain location.

Feel free to ask and to verify. But do it in the spirit of trust and collaboration.
A few years ago I was working with a team who was debating the question of button placement. The PM felt it should be in one location based on their experience even though the designs had it in a different spot. So the designer did some usability testing and found that the button placement performed best as he had designed it.

Definitely question. Definitely test. But have trust.

Keys to Success
When it comes to successfully working together, the best product managers and UX designers in my experience have all done a few things that have made a massive difference for their interaction and their teams.

Define Your Roles
When working together, especially as a product manager and product designer, it is critical to define your roles and your interaction. Have a conversation about how you will work together, what you will focus on, how you will interact, etc. How you work together will be critical for your team’s success, so take some time to figure it out. Everyone is different and every relationship will be different with different strengths and different needs.

As a product manager, I loved design and spent significant time on mockups, prototypes, etc. Partly out of necessity because there was more work and not enough designers, and partly because it was an area of interest for me. That was a discussion I had regularly with the designers I worked with. Other product managers don’t focus as heavily on those things, so having that understanding is important. Some designers are far more technical and venture further into the realm of product management, wanting to understand the business and technical aspects of products more than other designers, who focus more heavily on visual or interaction design. Neither is right nor wrong, but having a shared understanding of this is important.

Collaborate Constantly
Once you’ve defined your roles, you need to collaborate constantly. You should meet together regularly to calibrate and ensure that you are staying in sync.

Ideally the product manager and UX designer will work in lockstep. But like I mentioned above, the circumstances won’t be ideal. So you need consistent communication.

As a product manager/UX designer duo, how often are you meeting together? And I don’t mean how many meetings are you in together. How frequently are you actually sitting down and meeting one-on-one to discuss your products, work in progress, upcoming priorities, etc? The most successful interactions I’ve had were when I was doing this regularly with my UX counterparts.

Evolve Together
Finally, allow yourselves room to evolve together. Just as you will iterate on your product, iterate on your relationship and your roles. Things will change, and you will need to change as well.

That is why the first two keys are so important. Once you’ve created a shared understanding of your roles and are communicating frequently, you will be able to change and evolve as needed, both for your product and for your business.

Early in my career, I was working with a designer on a few small products for our company. I wanted to get more into design, but the organization had a pretty strict process for everything. However, we both realized that we wouldn’t get much done if we followed that process and that we wouldn’t learn much either. So we found the areas we could flex the rules a bit, and as our business needs changed, we could help move things along as well. It became an incredibly productive partnership as we both learned and evolved.

Product managers and UX designers aren’t Kirks or Spocks in my experience. We all bring some level of emotion and some level of logic. But it is that push and pull that creates the right dynamic for success.

By working together as a team, a product manager and UX designer can combine forces to create the best product and best experience for users and their business. The circumstances will never be ideal, but by defining your roles, collaborating and evolving together, you can create the magic that will make world-class products.

2020 is off to a raucous start. I don’t think any of us would have predicted things to play out quite this way. Even when I wrote about the shift to remote work a few months ago, I didn’t think the need for all of us to move quickly to remote work would happen so fast. But here we are.

As social distancing becomes the norm and teams, organizations, and entire companies move quickly to remote work, there are several things we can all do to smooth the transition and make it seamless for our teams, customers, roommates and family members. While I mean this to be helpful during the quick transition to remote work, the same principles apply for any transition to remote work.

Individuals
As individuals, there are several steps we can take to stay productive, keep things moving along for ourselves and our businesses, and help everyone around us keep their sanity.

Define Boundaries
Physical. Defining some physical boundaries will make the transition to remote work easier for you and roommates/family.

For those of us fortunate to have dedicated offices or work spaces, this is easier. But even with a dedicated office, you may need to redefine the physical boundaries now that you’ll be home more often. I know that my office gets used frequently for building marble mazes and other games, so now that I am working from home, my office has to be dedicated to work.

If you don’t have a dedicated office, defining a place for work will be helpful in establishing a routine and creating space and separation for work. If that’s a corner of the apartment or bedroom, or even the kitchen table during the day. It will be important to define the space for work, get it set up so you can be effective, and get everyone on board.

In his book Atomic Habits, James Clear talks about the power of establishing the right context by establishing predictable circumstances:

“Habits thrive under predictable circumstances like these. Focus comes automatically when you are sitting at your work desk. Relaxation is easier when you are in a space designed for that purpose. Sleep comes quickly when it is the only thing that happens in your bedroom. If you want behaviors that are stable and predictable, you need an environment that is stable and predictable.”

Temporal. Creating boundaries around your time will also be critical. Working remotely, especially if it’s new, can be a big change. It’s easy to lose yourself in things going on at home since you’re there, but it’s just as easy to let work bleed into your home life since there is no longer a boundary.

So setting up a schedule for your time “in the office” is just as important as it was before. It can be flexible, and likely will have to be since you’re also dealing with lots of other things (and during a pandemic, there’s a good chance you’ve got kids at home and many things to worry about). But keeping a good schedule will ensure you can continue to get important work done and also keep your home life somewhat normal.

Mental. Mental boundaries will probably always be the most difficult. It’s hard enough to define mental boundaries between work and personal life as it is, right? How do you not take your work home with you when it’s right there, all the time? How do you not take the stress of home to work when they are in the same place?

Creating physical and scheduled spaces will be helpful in getting some mental space. But allowing yourself some head space will also be critical. This will be a time for change. Give yourself some time to adjust! Take breaks. Take a walk. Be sure to clear your head regularly and find the right mental balance. Creating a routine, which we’ll discuss next, will also help with this.

Create (or maintain) a routine
If you’re shifting to remote work, either temporarily or more permanently, create or maintain your routine. As someone who has worked from home frequently, the most productive days I’ve had are the ones I’ve maintained my standard routine for work. That means getting ready like usual, even getting dressed like I’m heading to the office, and then stepping into my office and starting my work day.

I’ve even heard of people “commuting” to work by leaving their house, walking around their neighborhood, and then arriving back at work. I think it’s a great idea. Creating a ritual to get you in the habit for work will set the right tone. It is critical for success, especially as you transition from being in the office to being remote. I’ve found that transition periods are usually times when my routine slides, and that is when my productivity also slides. So maintain your routine if you want to stay productive.

Communicate relentlessly
We take communication for granted when we are all in an office together. We can always pop in whenever we need or schedule a quick time to catch up or meet. When we’re not all in the same space, that becomes more difficult, so we can’t take communication for granted.

Fortunately, the tools are all readily available. We just have to use them. That may mean changing some of our habits. But it is very doable. While we can’t just pop in for a quick chat, we can pick up the phone for a quick call. And we should do Zoom calls or video chats to keep face time.

We also need to keep records of discussions we’re having. So posting Slack messages, keeping meeting notes updated, and keeping everyone in the loop frequently is key. Over-communicating, especially in the early phases of the transitions, is critical. It is better that everyone feel like too much communication is happening than to feel like too little is happening. So don’t be afraid to communicate frequently.

Focus and Prioritize
So much of our work today has become urgent, lower importance items that take up tons of time. From emails to meetings to low-value tasks. As you shift to working remotely, especially if it is for a short period, take some time to seriously assess the high value items you can do. Prioritize that work.

The unfortunate fact is that many businesses will suffer as the economy turns. So we all need to focus our efforts on the highest value tasks we can perform and ensure that we are delivering value for our companies, our customers and our users. The more we focus, the more value we can deliver. And the more non-essential we can cut out.

Managers
As managers and leaders, we are now in the position to manage remote teams, whether or not we were ready for that. Hopefully, if you’re a leader, it is something you’ve been considering or have experience with. If not, welcome to the party!

Communication
Communication with your team will be the single biggest success factor through all of this. Communication about ongoing work, expectations, changes that are happening, etc.

As a leader or manager, you need to stay apprised of what is happening with your team. It won’t be as easy as walking around an office to get a feel for what is going on. Your team members can’t just pop in either. It will require effort on everyone’s part. And as a leader, you set the tone for the team. So set a standard of communication, especially early on by having regular chats with team members. They need not be long or comprehensive, but just ensure that you’re staying updated.

You will also have to strike a balance. You’re not trying to manage every aspect of your team’s work either, at least hopefully that won’t be the case. So you’ll likely need to find the right cadence. Communicate that to your group. Let them know that you will be finding the right balance and you’ll all be working together. You’re all in this together.

Expectations
Next, be sure to set clear expectations with your team. When will you be having meetings? When will you expect people to be available? What will communication look like? How will you handle issues as they arise? You may not have all the answers immediately, but starting to set clear expectations will avoid so many issues down the road.

In past teams, we set the expectation that we do video calls, video on for everyone so we can all see each other. That set the tone for the team so there were no questions.

In our current situation, we’ve set the expectation that team members have kids at home and that we are okay with that as a group. If kids pop into calls, that isn’t a surprise or issue for us.

As a leader, have these conversations with your team. Outline expectations and then document them so everyone is aware. You can keep documenting things as you go.

Documentation
And that’s a great segue to documentation. Documenting discussions, decisions, meetings, etc., will be even more than ever before. If you haven’t been in the habit of documenting things, this will be quite the change. But it will be a good change and a good habit to create.

Taking notes doesn’t have to be onerous. You can rotate the responsibility around the team so it isn’t a burden on any one person, or have someone dedicated to the task. You’ll want to ensure you note important decisions and action items so you can follow up in the future and so anyone who wasn’t able to be part of the conversation can catch up quickly.

Creating team documentation is an important key. With everyone remote, even for a short period, there is less ability for the regular interactions and so it is even more important to write down team norms, helpful hints, and other useful bits of information. Product management, for example, is learned much more by apprenticeship. But when everyone goes remote, there is obviously much less opportunity for that in a traditional sense. So we have to communicate more and write down as much as we can to help newer members of our team continue to learn their roles.

Metrics
With the turmoil and chaos surrounding everything right now, it would be wrong to expect performance of teams and organizations to be unaffected. As leaders, we should acknowledge that there is so much more happening than we can fully get a handle on. It is tough and may get tougher still. So let’s help our people do the best they can. That is our main purpose.

With that said, we all still want our companies to be successful (I hope). As leaders, we can’t manage by butts in seats. Hopefully that isn’t how you’ve been doing it, but that won’t cut it in a remote world. Therefore, we need to focus on the metrics that matter most. How can we ensure that our teams are delivering value? Find those metrics, make them obvious, and work with your teams to align your goals against them. And measure your success by them. Hint, it won’t be hours worked, lines of code delivered, or emails answered.

One ongoing practice for my team has been to set a few goals at the beginning of each week for the most important things to accomplish and then report back on those goals. I also do the same. More on that in another article. But it helps keep the focus on what is most important and ensures accountability.

Moving to remote work can be a huge benefit for many people and organizations. As part of a larger strategy, it is great. When it happens suddenly because of sudden events such as pandemics, it can seem like a strain initially. However, with the right steps, it’s not only manageable, but can be just as effective as being in the office. By creating the right boundaries and expectations, focusing on the right priorities, and communicating relentlessly as individuals and leaders, we can continue to be successful as teams and companies.
​
And as we manage the transition, hopefully we can incorporate remote work as part of our larger strategy going forward.

Hopefully, your team or company won’t ever get hit by the “blizzard of the century” that keeps you all out of the office for a week, but you never know.

Years ago I was scheduled to fly to the east coast just as a superstorm was about to blow through. I wisely postponed that trip and dodged what was a nightmare for weeks. Many people couldn’t travel to work, and many office buildings were without power (or running on backup generators) for days. I’m glad I wasn’t stuck in a hotel room without power for a week.

Those kinds of events can shut down teams, companies, and even industries. A major storm, a natural disaster, an outbreak, or just life. A few storms like that have inspired us to prepare our home with things like a backup generator and emergency supplies so we’re prepared for a snowpocalypse.
​
But what about getting our teams and companies ready? Fortunately, we don’t have to be doom and gloom about it, because the benefits are massive, and we can have them today.

The future of most knowledge work will be distributed and remote. As companies become more global and as connectedness shrinks the distance between people, going into an office to do the same thing you can do at home or at the coffee shop down the street will become an antiquated notion. In many places it already is. But this trend will continue to speed up and engulf organizations that have been slow to move.

And this future may come much sooner than you think. While the culture of an organization may not change overnight, you never know when some unforeseen circumstance may force everyone in your group or company to be remote for some period, like the superstorm that hit our team years ago. Or like the major disease outbreaks that are causing huge issues today. The coronavirus has caused tens of thousands of workers in China to work remotely as it has spread rapidly across the world.

Having been at organizations and offices across the spectrum of remote work, I’ve learned some key lessons about how to make your team or group the most effective no matter where you are on the spectrum. Whether your work is primarily or partly remote, you’re in the main office and interact with remote workers, or you’re part of a remote group far from the company headquarters, there are several steps we can all follow to improve the productivity of our teams and prepare ourselves and our groups to be remote friendly.

1. Define Your “Why”
As an organization, clearly define why you are shifting to more remote friendly work. Is it to remain competitive and attract the best local talent by allowing flexibility? Is it to expand your talent pool by hiring beyond the local market? Is it to lower costs? To diversify talent? To expand globally? Some combination? Those are all good reasons, so you should be able to articulate among them why you are becoming more remote friendly.

You need to have a clearly defined “why” and be transparent. There are likely benefits to your current employees, but it may also unnerve if you don’t communicate what you’re doing. With adding global talent, existing employees may wonder if their jobs will go away. You need to address that. Besides addressing concerns, if you don’t have a clear strategy, you won’t know if you’ve achieved your goals. If lowering costs is the goal but you never define that, how will you know you’ve been successful?

By having a defined “why”, you can incorporate this into your ongoing practices. Your employees shouldn’t be thrashed around by whims of new leaders or changing environments, so defining your remote working strategy ensures that everyone — from employees to leadership — understands what to expect and can get on board. Remember, many people make important life decisions based on company policies, so we should be thoughtful about how and why we do things.

2. Change Your Mindset
The next key is to change your mindset. If you are a manager or team lead, this will be a critical step.

Way of Working
While we once considered remote working a perk, we need to look at it as a way of working and a way of life now. Remote work is a requirement, not a fringe benefit. It’s not just a bonus which also means that it isn’t something that we can give and take away like a ping pong table in the break room. This is especially true for workers who are transitioning fully to remote work. And this trend will only continue. While not every employee will work remote full time, most employees will work remote at least sometimes.

Value over Outputs
Being in the office has long been a proxy for measuring productivity. That may have made sense 50 years ago when much of the work you needed to do had to be done in the office because that is where the documents were or the computer was. But with the connections we have today, everything is accessible everywhere, if we like it or not.

Rather than managing to perceived outputs such as time in the office, we need to shift to managing to outcomes and value. You’re right that measuring how much time someone is in the office is easier. But it may have zero correlation to the value being delivered. Someone could easily be in the office for 10 hours per day while delivering no real value. Likewise, someone could be in the office for 1–2 hours in a week and deliver significant value to the business or customers.

Watch Your Language
“Sh*t.” — Iron Man

“Language.” — Captain America.

That’s not the language we’re referring to here, though you may want to watch that as well depending on your work environment. What we mean here is watching how you talk about work. It's easy to forget how different it can be for our remote colleagues, especially anyone who is remote full time.

Be sure to be inclusive. It's easy to talk about how great it is to be together in the office, or how great face-to-face communication is. However, that can feel hurtful, especially if someone is remote full time. These kinds of comments are especially difficult if they come from leaders. If someone is remote or part of a remote office, they already feel somewhat isolated. Therefore, comments from leaders that further exclude them only widen the divide. As leaders, especially with remote workers, we need to ensure that everyone understands that we value their work and their contributions regardless of where their desk is located.

Cultural Shift
Being a remote friendly organization will be a cultural shift. This will probably take some time. But being transparent about it and shifting your mindset will make the transition much smoother for you, your team, and your company.

3. Think Remote First
In recent years there has been a shift in software development to “mobile first.” This has meant that design and development should focus first on making an excellent experience on mobile devices and then take that to the desktop.

The reason for this is twofold: First, it is much harder to get something right on a tiny screen. There is not a lot of real-estate to work with so you have to be very conscious of what you do and what makes it onto the screen. Second, people have shifted to using mobile devices as their primary source. Since we’re no longer tied to desktops for most of the functionality we need, we expect to do everything on our cell phones and tablets. And rightly so.

We need to take the same approach to remote work. We need to think remote first. The reasons are very similar to the thinking with mobile first: First, it is harder to get it right. In-person is easier, so shifting to remote first is a challenge. Second, many people are shifting to this mindset for their own work. Similar to being able to access anything on our mobile devices, the expectation for work is following suit. We should be able to expect the ability for people to be mobile.

Make Every Meeting Remote Friendly
At one company I worked for, I was in the main office and we had a few remote team members. At first, this was challenging since most of us were in the office. We defaulted to focusing on the group in the office. But this didn’t allow for broad participation. So we shifted our focus.

We started by ensuring that every meeting had a dial-in and I started bringing a camera to connect the room and remote folks. As we got comfortable with this format, I realized that getting people into a conference room was unnecessary. We could shift our meetings to be entirely remote for everyone. That meant that team members could stay at their desks if they needed, or work from home without having to worry about meeting schedules for the day.

Make it a regular practice to make meetings remote friendly, and you’ll see a big change in your ability as a team or department.

Get the Tools
A key to making this shift work is ensuring that your groups have the right tools. Today, there is no shortage of excellent tools to use for communication. Slack for chatting. Zoom for online video calls. Microsoft Teams for either of those. A host of other options exist. There is no excuse not to leverage these tools, whether on a small scale or across an enterprise, to allow everyone access to team collaboration.

One of the key benefits of being in a conference room is often the white boarding or brainstorming that can take place. However, I’ve found excellent tools that allow for that same collaboration done across offices or remote employees. My favorite is Lucidchart, which allows many people to edit at the same time. I’ve used it as an online board for writing ideas in real time, and a board for sticky notes that an entire team can contribute to. This has been awesome as we’ve created user story maps, brainstormed ideas, or gone through similar exercises as a product or development team.

Document Discussions & Decisions
One of the biggest changes to remote friendly work is documenting meetings, discussions, and decisions. This is critical because you need to ensure that everyone is aware of decisions being made whether or not they were present. And when teammates are remote, whether full time or just on and off, you need to have good documentation that everyone can refer back to.

I’ve found that this is just good practice. Whenever I’ve gotten away from the habit of documenting discussions, meetings or decisions, it has come back to bite me. Several months ago we were in discussions on team structures. The conversations were all in person and were moving quickly. Unfortunately, we didn’t write much down. So when some questions arose later on, we had nothing to refer back to other than our memories of what we had discussed. Which were an imperfect record. I kicked myself for not writing the decisions we were making as we went. This would have been even more difficult if some of the team had been remote and wouldn’t have been available to talk in the office. Don’t make the mistake I did. Write things down.

4. Ensure the Right Fit
Hire the Right People
Hiring the right people is a key to anything, and that holds true here as well. If you’ve got a team of people that you can’t trust to work remotely or unsupervised, you likely have bigger issues.

So hiring folks who you can trust is critical. Teams should think about that in making hiring decisions, from the managers to the team members. You should think through the questions:

• How will our interactions be if one of us is remote?
• Can we be confident this person can get their work done without significant supervision?
• Are there any barriers that may cause issues if we are all remote?

Ideally, a team should be able to function whether or not everyone is in the same place. But even if your ideal is complete co-location, be prepared because not everyone will always be in the office. If you plan around that, especially with having the right people, you’ll be able to continue to deliver quality work as a group, even if the situation isn’t ideal.

Find the Right Balance
We also need to understand that remote work isn’t for everyone, and to be successful we need to properly support teammates who will work remotely or in remote offices.
Jessica Pamdeth a staff engineer for WGU, recalls her time working for IBM when they shifted to remote work for the engineering teams:

“When IBM sent us all to work remote, about half the folks started looking for new jobs right away. Not everyone has a good space in their home for working. Perhaps they have young kids at home every day, or their place is just too small for a dedicated workstation. Maybe they can admit to themselves they don’t have the discipline. Or they just prefer the interaction with coworkers every day.”

Regardless of the reasons, full time remote work may not be for everyone, so it is important to understand that. Everyone seems to have varying degrees at which they can productively work remotely. As a manager, it’s important to understand that and find the right balance for your team and your organization.

5. Set Expectations
Once you’ve created your remote friendly workplace, it’s important to set the right expectations for your team and organization. The level of formality will vary depending on the situation, but it is important for your employees and their development to help them understand how they can progress, especially if they are remote.

Promotions
In one of my previous roles, one of the most senior members of the organization was a remote employee. And she was a phenomenal employee. But because she was remote, they limited her in moving into a VP role. While she essentially ran the entire department in that capacity, they refused to give her that promotion, which was unfortunate.

It’s important to be clear how far employees will advance and be promoted in remote roles. Will they be excluded from management roles? Should they be? You may not have all the answers to these questions yet, but think through them. If you will exclude remote employees or expect them to move to your main office for big promotions, you may end up losing out on some of your best talent. Is that something you’re willing to do?

Asynchronous Communication
How do you expect employees to communicate? This is a broader question and is often overlooked when most employees sit in the same office or in the same time zone. But it gets more difficult as employees stretch across offices and time zones.

Allowing employees to have focus time is critical, especially in knowledge work. So setting the expectation that most communication (except for urgent matters) will be asynchronous may be a great idea. That way everyone can handle communication when it fits their schedule rather than when the Slack notification hits their phone or laptop.

No Second-Class Citizens
When we were setting up the Salt Lake office for Goldman Sachs, many people in New York and London viewed it as a second-tier office. A place where they could send crappy work they didn’t want to do so they could focus on sexier projects. It took some time to get everyone away from that idea, but we eventually did.

If you’re setting up a remote office or remote workers, don’t do it with the view of second-class citizens or a place to send your shit-work. That will be a way to get a lot of disgruntled employees quickly. You want full teammates. It will be better for your team and your company in the long-term. Even if they are less expensive in other locations, that doesn’t mean they are less valuable.

6. Give Teams Autonomy
Once you’ve got the mindset, the tools and the people in place, it’s time, especially as a leader, to give teams autonomy to find their cadence. Not every team functions the same. Humans are complex, and our interactions are complex. Leaders at high levels should allow their teams flexibility to find the right cadence. Allow the leaders within groups and teams to find the right solutions. Let go of some control and let your people find the solutions that work!

For people to do their very best work, it often means they need the right environment, free from distractions, to immerse themselves and perform at their peak. Modern offices are notoriously bad environments for this type of work. They are full of distractions, from meetings to phone calls to quick questions. By focusing on value delivered and allowing employees to work wherever they can deliver that value best, we can continually move in the direction of becoming remote friendly.

For team leads and team members, it is critical to show the value that you’re delivering to your organization. If you will not be measured by the hours you’re in your chair in the office, you need to make it easy to show the actual value you’re providing.

7. Promote Face Time
None of this is to say that face-to-face interactions aren’t important. Humans are social creatures. It’s in our nature. We will not change hundreds of thousands of years of evolution with modern technology and we shouldn’t pretend to. We need time together as a group. So it is important to bring remote people together periodically to create those uniquely human bonds.

This is especially important if most of the team is located in an office with a few remote members. In one of my roles, I was in a remote location while the rest of the team was (largely) in New York. I made a point to travel out there every few months to work in person. Most teams I’ve worked on have had a similar policy, but it’s important to make sure that remote teammates join the team periodically, especially during important events such as product launches or celebrations. This is particularly important for teammates who are the lone remote members of the group, or in the minority. It is easy to feel isolated when you’re the one far from the team, and it is easy to forget how difficult that can be when you’re not the one who is remote.

To make face-to-face time more meaningful, you can maximize the usefulness of your team’s time together by focusing on shared experiences. This means rather than continuing with business as usual, ensure that you’re taking time as a team to build relationships by solving problems together, cooperating on shared goals and maximizing interactions.

8. Make the Effort & Commitment
Ultimately, it comes down to making an effort and commitment. Many people think co-location, especially of development teams, is the only option. I disagree. I’ve seen high-performing teams that are largely remote. And poorly performing teams that are co-located. It comes down to the team and the effort. I wrote about this in another post, Co-Located vs. Remote/Distributed Teams: What Works and Why. While it takes more effort to reduce the social distance of a distributed team, with the right leadership and the right tools, the team can bond and perform just as well as a co-located team.
​
On teams that are remote or have remote members, it takes an extra effort to keep everyone involved. But that effort becomes second nature with some practice. Calling folks up to chat for a few minutes may seem strange at first, but becomes normal quickly. By changing the mindset of the team, remote work can quickly become a default that is easy to manage and easy to execute.

Becoming remote friendly will be critical for businesses and teams to succeed. But the benefits will be huge. Businesses will access a global talent pool, or at least a far larger talent pool than just the local one. For many companies, this will mean great employees and lower costs.
​
The benefits to employees will be huge too. As we shift from the mindset of being tied to a particular location to do all our work, we will be much more free to find the time and place that best suits our productivity and passion.