The challenge we see with current updates is the lack of connection between weekly action items and OKRs. Yeah, we have the questions about the main OKR next week. However, it doesn’t really show what you did for specific OKR last week.

So, OKR-based updates solve this problem.

IMPORTANT! OKR-based updates work only on the web platform. If you want to use the Focus bot for Slack, you should run classic weekly updates. Yeah, it’s still possible to use classic weekly updates.

How it works

To show you how OKR-based updates work, I want to mention how classic updates work.

You can see in the picture above how the classic update works. We have 3 questions, which help to align the team on a weekly basis. 

The questions:

• What did you accomplish last week?
• What is your key insight of this week?
• How was your experience at work this week?

About OKR-based approach

The OKR approach is based not only on weekly updates but on weekly plans too. 

Everything starts on a weekly plan now. 

Answering what you are going to do this week, you should choose OKRs and specify action items for each OKR.

It’s time to work now. 

At the end of the week, you run a weekly update. And you have here your weekly OKRs and action items you have mentioned on the last weekly plan.

Also, you can add something that you haven’t mentioned on the weekly plan.

You should only choose it is completed or not. If it’s not completed, the system asks you for details.

However, the main goal of the weekly update is specifying OKR you were working on last week and connecting it with action items.

It allows seeing the detailed traction on your progress. How much the OKRs were moved for the last week, what you accomplished, what wasn’t accomplished, and why.

It gives you a better understanding of what you should improve and how strong you are following your OKRs.

How to set OKR-based updates?

If you want to use OKR-based updates, drop us a message via support@usefocus.co. We will set everything up for you.

Cheers!

Best,
Anton

The post OKR-based updates appeared first on Focus.

While speaking at many management conferences, I see that a lot of people struggle with setting OKRs (objectives and key results). The most important part I want to point out is that people often make similar OKR mistakes. 

In this article, you find the top 5 mistakes that companies make when setting OKRs and the ways on how to avoid them. If you follow these steps, you will save a lot of time for yourself and for your team in OKRs implementation. And of course, you will bring out the next level of creating an environment that values and emphasizes output.

Topics covered in this article:

• What is OKR?
• What are the obstacles that come with OKR?
• Top 5 OKR mistakes

Before we begin, I want to mention the main benefits of OKRs because it allows you to understand what you should be getting out of them. And no one can tell better about it than John Doerr, who worked with “The Father of OKR”, Andrew Grove. In his book “Measure what matters”, he describes four OKR superpowers:

• Superpower #1 — Focus and Commit to Priorities: High-performance organizations hone in on work that’s important, and are equally clear on what doesn’t matter. OKRs implore leaders to make hard choices. They’re a precision communication tool for departments, teams, and individual contributors. By dispelling confusion, OKRs give us the focus needed to win.
• Superpower #2 — Align and Connect for Teamwork: With OKR transparency, everyone’s goals—from the CEO down—are openly shared. Individuals link their objectives to the company’s game plan, identify cross-dependencies, and coordinate with other teams. By connecting each contributor to the organization’s success, top-down alignment brings meaning to work. By deepening people’s sense of ownership, bottom-up OKRs foster engagement, and innovation.
• Superpower #3 — Track for Accountability: OKRs are driven by data. They are animated by periodic check-ins, objective grading, and continuous reassessment—all in a spirit of no-judgment accountability. An endangered key result triggers action to get it back on track or to revise or replace it if warranted.
• Superpower #4 — Stretch for Amazing: OKRs motivate us to excel by doing more than we’d thought possible. By testing our limits and affording the freedom to fail, they release our most creative, ambitious selves.

Sounds good? Then let’s talk about the definition of Objectives and Key Results and what OKR mistakes teams often make using them.

What is an OKR?

OKR (Objective and Key Results) is a goal-setting method used by Google, Netflix, and many others. If you want to get a key difference between KPI and OKR then think about it as the difference between Waterfall methodology and Agile. I hope it helps ?

To clarify, OKR is a framework for setting ambitious goals that help a company focus on the most important issues. There are no hard commitments and bonuses for achievements. It also doesn’t impact the performance scores. In contrast, OKRs are ambitious, almost unachievable goals that continuously sync the progress.

OKR consists of 2 pieces: 

1. An objective is an ambitious goal, which motivates and inspires the team. It shows WHAT we should achieve.
2. Key results are metrics that measure HOW we get to the objective. Are we in the timeframe? Should we increase the velocity or change the goal? Are we going in the right direction or are we losing focus?

OKR principles 

It’s important to understand not only the shape but also OKR principles:

1. Publicity and transparency – everyone can see all OKRs. 
2. Ambitious – some OKRs should be at least 3-10 times higher than usual goals to motivate people on finding new and creative solutions. 
3. OKRs don’t impact salary or bonuses – people will not set ambitious objectives if they know that they could lose their income.
4. Constant tracking – OKR syncing should be at least bi-weekly. However, running weekly updates is a much better way of tracking OKRs. It helps a team be aligned and change initiatives if it’s necessary. 
5. The fewer objectives and key results are better – it helps to focus on the top priorities and achieve the best outcome instead of trying to complete too many goals and get the worst traction. There should be no more than 5 key results for an objective. Less is more. Also, don’t create more than 5 objectives in a quarter. 
6. 50/50 or 60/40. OKR is not a top-down goal-setting system like KPI. The exec team sets 40-50% of OKRs and employees create the other goals. It’s the mix of top-down and bottom-up goals that generally settles at around half-and-half.
7. The OKR cycle is a quarter. OKRs set clear quarters, but you can change yearly OKRs if it’s necessary. Quarterly OKRs gives you a combination of agile and clarity. On one hand, you can react pretty rapidly to the market’s changes or customers’ demands. On the other hand, you have clarity of the top priorities for the next quarter. During some major forces, like the COVID-19 pandemic, some companies move to monthly cycles to change goals faster in times of ambiguity.
8. Key results are only metrics. Sometimes companies use indicators like reference points or tools for employee motivation. In OKRs, we use key results like coordinates in a GPS tracker. It’s only about the current status, not about motivation or bonuses. They help us keep the right of way, adjust the speed, and change the tactics. It’s crucial for a team because they show everyone where we are now and where we are heading. It allows a company to be a united team that can adapt to the environment and different contexts. 

We looked at what makes OKRs powerful and what to pay attention to. Now let’s move onto tackling OKR mistakes.

OKRs are hard, but making OKR mistakes are easy

Everything sounds great and makes sense, right? OKRs are great! Then why are you reading an article about avoiding OKR mistakes? When you’re first starting to implement OKRs in a company, problems usually arise. Someone doesn’t want to achieve objectives that don’t correlate to salary, others can’t make the right and ambitious objectives or set useful key results. There are many problems that a team runs into during the first OKR cycle and it is easy to run into these common OKR mistakes.

When a company thinks about using OKRs, they should know that the company’s culture will be changed – such as emotional maturity in the workplace, employee responsibility, communication with colleagues, and feedback skills.

The good news is about the timeframe. Goals can not be achieved in one night. What you can do is implement OKRs and transform your processes and skills sprint by sprint. And the most important thing to do is to analyze the strengths and weaknesses of your company and to create the right OKRs strategy based on these insights. 

Instead of a heroic two weeks sprint of OKRs settings, it’s better to implement the new framework wisely with less speed, but more effective. This approach allows OKRs to live in organizations when a founder stops spending too much attention on it.

The best approach is to establish a cross-functional team that will be responsible for OKRs implementation. Usually, the consists of the board of directors and from five to ten leaders from the organization. People from this team should get training on OKRs to properly understand how they work. Afterward, the team makes a step-by-step plan on OKR implementation and starts working on it. It’s important now to avoid those OKR mistakes that hundreds of companies have made before you. Let’s check them out.

5 most common OKR mistakes

OKR mistake #1: Too ambitious or too simple OKRs

One OKR mistakes we see companies make often is where the objectives they set are either too complex or too simple. And we did the same in the first iteration of OKRs. We set the OKR ‘Triple our sales in the quarter‘. It was a pretty ambitious objective, however, we didn’t have appropriate resources at that time to fulfill this goal. At the end of the cycle, we were exhausted as we achieved an objective of less than 10%. 

At the same time, we see many cases when companies set simple OKRs like ‘’Create the new website”, which probably is not so ambitious and hard to do. 

You should try to avoid setting very simple or very hard objectives. How do you set an ambitious, but not impossible OKR? 

Answer these 2 questions:

1. Will we achieve X in 3 months in our usual mode? If we understand that it’s achievable then it’s a simple goal. If not then it looks ambitious and we ask the next question.
2. Will we achieve X in a year? If we feel that we might do it – it will be hard, but we could achieve it in a year, then it looks like a good candidate on OKRs for a quarter. If we understand that we won’t be able to achieve it in a year, then it’s most likely your setting an impossible OKRs. 

Setting the right OKRs is the skill that a team improves step by step from quarter to quarter. Your first OKRs should not be perfect, because trying to do something ideal from the first attempt can take a lot of time and it also directly affects your enthusiasm. Feel free to set good enough OKRs to start using it early and then run an analysis, which will improve your next goals. 

Bad OKR:

Objective: x10 revenue in the next quarter
Key results: 

• Increase traffic on the website from 10,000 up to 50,000
• Increase Visitor-to-Customer conversion rate from 1% to 2%
• Achieve $10,000,000 in revenue

Why is it not a good OKR? On one hand, it’s a pretty ambitious objective and should inspire team leaders. However, there are two issues in the objective. First, the objective is not necessarily a measurable goal. Numbers in the title don’t inspire people in the team because they can think that it’s just boosted indicators. Second, the objective is too ambitious and it’s unrealistic in most cases. Increase revenue up to 10 times in a quarter – do you and your team believe in it? It’s hard to do in a year for most companies. And it’s even more difficult to achieve in a quarter. If your team won’t believe it’s possible then they will delay initiatives because employees often have a lot of tasks to do.

How can we transform this OKR and make it better?

Strong OKR:

Objective: Achieve a sales record in the next quarter
Key results: 

• Increase traffic on the website from 10,000 up to 50,000
• Increase Visitor-to-Customer conversion rate from 1% to 2%
• Achieve $10,000,000 in revenue

Now, this OKR looks pretty ambitious and we aren’t using numbers in the objective, which is really good for motivation. It’s a significant, concrete, and action-oriented objective that inspires the team. 

OKR mistake #2: Too many key results or objectives

Another OKR mistake we see is creating too many key results or objectives. In this scenario, companies lose their focus using the framework that was designed to keep them focus. Less is better.

How can you determine if there are too many OKRs? John Doerr recommends using 3 to 5 key results for an objective. The less is more. We prefer using 3 key results in many cases and set 5 results only if we don’t have another way. 

Using too many key results leads to a loss of focus on the most important things because the team will be doing a lot of different stuff. That’s why it’s better to set three or four outcomes to the goal.

Also, teams have similar mistakes with objectives. Some departments have 5 or even more objectives in a quarter. It also brings your team down a level when you are doing so many different things and wasting your attention in different areas. 

How many objectives should a team have? 

Again, John Doerr recommends 5-7 objectives for a company. We suggest setting 1-3 objectives for each level of your organization. 

OKR mistake #3: Using only top-down OKRs

This mistake often is made by autocratic leaders who think that OKR is the same as KPI. They set top-down OKRs for all teams and then it doesn’t get significant outcomes because people don’t believe in these ambitious goals and don’t understand why they should achieve them if it doesn’t correlate with bonuses. As a result, leaders think that OKRs don’tt work. 

OKR is not an autocratic top-down goal methodology. It’s all about people participating in this process. Each team thinks about its OKRs. People begin to understand the company’s objectives and how they contribute to the total outcomes, what’s the value they give to the company by their day to day operations. 

It helps everyone to see the real value of his or her works. And this is the place where the magic happens. People understand the company’s goals and know how they contribute to it. They set ambitious OKRs for their teams or for themselves. It’s a game-changer for employee engagement. 

However, you will not achieve this by highly hierarchical top-down goals. These goals are not connected to people’s views and desires. They might think, “It looks that our management wants us to work hard for achieving these ambitious goals without paying bonuses for it.” Do you think that motivates people? Top-down autocratic goals don’t encourage people to do great.

That’s why it’s crucial to build a culture where top-down goals work with bottom-up objectives. C-Suites determine a company’s OKRs. It’s high-level objectives for the whole organization. At the same time, teams start a discussion about their visions. What value they will put on the table for achieving the company’s goals. In this process, department heads talk with their people to determine the best and the most ambitious goals for them. Afterward, teams present their OKRs to the C-level management and make it public after confirmation. 

You see, everyone participates in the goal-setting. It’s not just a management game. People in teams begin to take care of the objectives because they participated in its creation. If you use OKRs only top-down then change it as soon as possible and give your people the opportunities for participation in this process. 

OKR mistake #4: Don’t track progress regularly

OKR is not a silver bullet that works after they were identified. You can’t set OKRs and forget about them until the end of the cycle.  

People are used to tracking metrics and indicators in both ways – either it was requested or before bonus pay. In OKRs, you should do it regularly at least one time per two weeks. However, weekly updates work much better in most cases. In this case, OKRs fulfill their destination, which is to be the coordinates for your organization and link strategy with tactics. 

Let’s imagine that you are going on a journey from San Francisco to Los Angeles. You turn on the GPS navigator to check the status. If you know the road, then you don’t need a GPS navigator. However, it works only for well-known goals that you’ve already done before. But if you don’t know the route and you don’t look on the navigator then each turn in the road could lead you to the wrong place where you are moving further from your way each minute. 

That’s why it’s crucial to set the specific day on the week and do weekly (or bi-weekly) OKRs updates. 

It doesn’t take a lot of time to do weekly updates. It unites your team across top priorities, which is a very important benefit for everyone. 

How can you track OKRs weekly? 

• First, you should answer this simple question, “What’re your OKR achievements this week?”. If you didn’t do anything regarding OKRs, then ask yourself why not? You should analyze this issue and take action on how to improve it for next week.
• Second, see who worked on OKRs this week – what’s about your key results? Are they changed? What’s your current status now – are you on track, behind, or at risk? Write everything down that everyone understands total progress. Keep it transparent.
• Third, are there areas for improvement? What can you or your team improve on for next week? Did you achieve any planned outcomes this week? If so, you can probably set a more ambitious goal for the next week. If not, then what were the main blockers? What can you and your team improve in the next sprint?

See, magic is here. Everyone analyzes their OKRs outcomes weekly and gets insights from it. Your team starts thinking about OKRs each week, which means that you are thinking about what matters the most, constantly. It sounds simple, but it’s so powerful. 

You can track your OKRs in sheets or in special software like Focus. You need to begin building a habit of weekly retrospectives and creating a transparent culture that values and emphasizes output. Learn more about how to run short scrum meetings in the linked article.

OKR mistake #5: Using results that a team doesn’t know how to measure

Some companies create very ambitious key results like ‘Increase NPS up to 2 times.’ However, sometimes when asking them about what’s the current NPS (Net Promoter Score) you hear silence because they don’t know it. 

And how will these teams track their progress and achievements?

In the case of NPS, it’s pretty hard to measure the score in several days. You need time to implement it on websites, newsletters, and so on. Then you should receive the data from customers. It takes time. If you have an OKR with increasing NPS by 50% this quarter and you haven’t implemented an NPS system yet, then you might have some problems with it, because you’ll be spending one or two months just setting up an NPS and receiving your first batch of data. With each weekly update, you will say something like this, ‘We haven’t had data for measuring NPS yet’. That’s why it’s better to set a key result as ‘Implement an NPS system’ and track how many initiatives you will finish for this key result. For example, if implementing an NPS system consists of 30 to-dos and you close 27 that means that you complete this key result at 90%.

When setting a key result, you should think about how it’s measured. Also, remember that they are indicators. Key results should tell a team about progress, so everyone can adjust his or her goals, accordingly.

OKR checklist

Phew, those are some big OKR mistakes, right? We gathered the most popular OKR mistakes in this article. However, it’s not all the mistakes companies make during OKRs implementation. That’s why I’d like to finish the article with a check-list that helps you to improve your OKRs. If you want to know more about OKRs, you can read this article on how to set powerful OKRs.

Check that your objectives fit these criteria:

• Objectives have a quarter cycle
• The objective is WHAT we want to achieve
• The objective helps to achieve high-level goals or other teams get value by achieving that objective
• You have 2-5 objectives per team’s level 
• 50% or more objectives set bottom-up
• Goals are divided into two types: ambitious and operational

Check-list for key results:

• 50% or more key results set bottom-up
• Key results are measurable and clearly describe achievements of objectives (at least “done/not done”, but it’s better to avoid this version)
• Track progress each week (or, at least, bi-weekly)

Summary

We looked at what makes a good OKR, what challenges you can face in your organization, and what common OKR mistakes to avoid. I hope they will help you in setting the right OKRs that will bring your team to the next level. And remember that the main mission of OKRs is to unite your company while making the focus on top priorities and transparent culture. 

Finally, I believe that identifying top priorities and consistent focus on it day-to-day is the best way for building high-performing teams. That’s why we created Focus, a tool that keeps teams on top priorities every day. Start working smarter with Focus.

The post 5 OKR Mistakes and How to Avoid Them appeared first on Focus.

We interviewed Madhuri Aggarwal, a senior business consultant solving product challenges for clients such as eBay and Cisco. Madhuri shared her expertise in product management and favorite tools and processes she uses on a daily basis. 

What’s your background, and what are you working on?

With a masters in marketing and computer science engineering degree, I sit at the intersection of Business, Technology, and User Experience. I have led multiple IT projects from ideation to execution for my employers and clients alike during the last 8 years. I really enjoy synthesizing customer and business needs, defining and driving product roadmaps for developing client facing platforms and employee facing applications.

Apart from supporting my client in their business continuity planning efforts amidst the COVID-19 crisis, these days, I am devoting my time on community building efforts.  

Can you describe your current role and how you got started in product management?

Out of business school, I found this amazing opportunity to work at an Indian SMB that offered a Marketing Rotation program. While there, I fell in love with product management—and that led me to a job at a Silicon Valley startup and later Cognizant Business Consulting. My consulting job has taught me how to uncover problems, identify solutions, and more importantly, how to build and market some of the cutting-edge technology offerings. 5 years ago, I got the opportunity to lead product lifecycle management responsibilities in order to bring a B2B solution to life for my client, eBay. Since then, I am helping them – as a Product Manager- in developing platforms & applications while delivering lasting experiences and business value.

Could you tell us about your day to day? What technologies and methods do you use on a daily basis?

Product manager responsibilities vary not just from company to company but also at project/team level. Due to this variability, there is a wide range of day-to-day activities, but ultimately, a product manager is still responsible for doing whatever it takes to collaborate with multiple teams and move different conversations towards closure.

On a typical day, right after checking my emails, I like to prioritize and stick with 3 or less things that I want to achieve on that day. Being prompt about answering my customer or team’s questions or concerns, standups or other sprint meetings, stakeholder meetings, requirement definition or backlog prioritization within JIRA, keeping abreast of industry trends are some of the other tasks my job demands on most days.

At eBay, we follow agile. Agile works best with projects with uncertainties as this methodology allows quick iterations as per the user validation. However, you need to keep an open mind, be adaptable to change, and assess the risk to cope with agile methodology.

• Using a tool such as Zoom allows not just virtual meetings but makes it easy to record conversations- to be referenced later. 
• Gartner for the collective industry research and the latest thinking of the analysts to help determine where your market is headed.
• Axure for wireframing
• Slack for team messaging
• Visio for flowcharting
• JIRA for project management but I also love the simplicity of Trello and intuitiveness of Asana

This doesn’t mean that MS Office 365 shouldn’t have a prominent slot in your product management toolkit.

What are the biggest challenges you’ve faced and the obstacles you’ve overcome as a PM?

While building a product from 0 to 1, it required the use of different mental muscles and a deep understanding of all of the factors in a launch, not just the ideation and writing requirements. Everything from operations, how do we sell, how do we support, how do we go to market, how do we measure, etc. was a grilling exercise while I was building eBay’s first business-to-business platform. Scaling from 1 to N was another beast for the same platform in a different industry and in different geography.

Apart from these complex problems, I had one issue in the past and I believe many Product Managers have is, ensuring that their successes and the value they deliver are articulated across the organization. This is so important as you could be doing an amazing job at delivering features one after the other and oftentimes, you tend to get so involved in delivering a great solution that you forget to tell people what you and your team have achieved. This can lead to people not understanding the value you or the product bring to the organization. I am not claiming to have addressed this completely, but I am getting better at analyzing.

What are your favorite ways to learn more about your users?

• Feedback from users directly- but more often, you don’t get a lot of it.
• Quantitative research – numbers can unravel behaviors that might be difficult to discover during an in-person interview
• Feedback from or through customers teams or partners
• User session recordings to see how the users interact and their journeys
• Assume now and test later approach when we lack any substantial information about my existing users

Do you have tips for managing teams in different timezones?

When it comes to remote teams that work across time zones, structure and order are everything. The more people work on your team, the more important is it to establish processes and procedures for everyone to follow with a clear escalation path if an issue arises. Developing a Code Style Guide has helped my teams spread across multiple geographies.

• Building relationships – not just business ones, but personal ones, with all stakeholders, is as critical as voicing appreciation and celebrating the wins together.

• Have one time where everyone can get together in real-time. This invariably requires sacrifice for somebody, but it’s important.
• For better communication, I use time overlaps for conference calls and/or joint team assignments and whenever possible, meet virtually through videoconferences
• I emphasize JIRA or Slack for Asynchronous Communication

Being constantly in touch with all the team, not only the customer, is key to building a good relationship with them and this will help you to create better products.

How often do you run meetings? How do you run them? Does your team run standups?

Apart from a daily scrum, we do Sprint Planning, Sprint Review, and Retrospective every 2 weeks. Backlog grooming is typically monthly to fill the gaps, only if the PM deems it necessary.

We work using Scrum, so it’s a matter of keeping track of work with the dailies in each sprint. After a few sprints, you’ll get to know the capacity of your team in order to be more effective when planning the next ones and also to prioritize your backlog.

During daily scrum, every team member answers:

1. What did we do yesterday?
2. What are we doing today?
3. What is in our way?

Before the sprint planning meeting, I ensure that all items in the backlog that could be considered for the sprint (features, bugs, optimizations, stakeholder feedback, etc.) meet the team’s definition of ready and are not too large or small.

As a PM, I keep the roadmap both current and visible to the whole team inside of Jira before the sprint planning meeting. Everyone keeps their availability updated in project wiki.

During the sprint planning, I will present the sprint backlog to the scrum team and look for alignment. If items are not estimated already, we estimate them to get a sense of how many can be selected for a sprint. We discuss any issues, assumptions, or dependencies before the team can go back to work.

At the end of the sprint, we review the increments and check the backlog. I ensure that the definition of done is met for the increments and that the QEs do not have any issues. The entire group then collaborates on what to do next.

During the sprint retrospective, my scrum team discusses what to:

• Start doing
• Stop doing
• Continue doing

How deeply should product people know about marketing strategy, UX design, and coding?

In my experience, background doesn’t make much of a difference. You should go towards where your passion is. And, as long as you’re not afraid to learn on the fly, you’ll be fine.

Do you have coding skills?

As a computer science engineering student, I did code quite a bit during my undergrad but never had to, after then. I wouldn’t hesitate to, as a PM, if a project demands.

What skills do you think would be most valuable to learn and prioritize for an aspiring PM with no technical background?

Good product managers know what they don’t know and are excited to learn about it. They have a basic familiarity with technology and are curious to understand how a product works.

My advice to the PM aspirants with no technical background would be to learn how to solve problems before attempting to learn to code. Be aware of the technical goings-on and trends in the industry. Learn tracing through the product flows to understand fundamental user issues. Know the difference between ‘urgent’ and ‘important’ which can be a difficult distinction to make. Learn to empathize – not just with your customers but also with your developers. As a PM, the more I asked questions to the developers and genuinely listened, the better I could appreciate and represent their point of view. 

If you understand your product, communicate effectively to technical and non-technical audiences, eager to learn, and stay organized, you’ll be ahead of the game.

The post Madhuri Aggarwal: About remote work, technologies, and skills for PMs appeared first on Focus.

This week, we interviewed Jedrzej Kaminski, a Product Manager at EyeEm. Jedrzej shared his expertise in A/B Testing and data analytics to discuss measuring success when conducting research. He also answered burning questions on technologies he uses on a daily basis, his experience at EyeEm, and how to make different transitions into Product.

What’s your background, and what are you working on?

I have a master’s degree in psychology, but was always interested in technology – even my final thesis was about an online adaptation of pen-and-paper test to measure creativity, so I spend half the time doing research and half coding. I’m working right now as a Product Manager for EyeEm – an AI driven Marketplace for photos delivered by a vibrant and talented community. 

Can you describe your current role and how you got started in product management?

My career in IT started in Quality Assurance. While performing other responsibilities like manual and automated testing, I’ve found that talking to our community, participating in the user research and crunching the analytics numbers are quite enjoyable. They were also very close to the user-centric mindset I gained when trying to find bugs before our users. I wanted to try the Product role and EyeEm gave me an opportunity to do that. Now I’m a part of two cross-functional teams focused on driving business KPIs. 

Could you tell us about your day to day? What technologies and methods do you use on a daily basis?

My day to day activities heavily depend on where are we, as a team, in the project development cycle. 

During product discovery it’s more about analyzing the data, user behavior, quantitative and qualitative, to find the problems, frictions and struggles we can help them with. Formulating those problems is crucial, because then we know that the team work can be most impactful. Amplitude, Google Analytics, Tableau or just doing SQL queries – those are some of the tools that are helping a lot with quantitative analysis. You can also use Typeform or even Google form for more open, qualitative responses, but live user interviews are always a goldmine of insights. Obviously, nowadays, when we tackle the COVID-19 issue, we are doing video interviews instead.

After that it’s all about planning and ruthless prioritisation and looking for the smallest possible implementation of the feature that you have in mind, that can give us data to confirm that we are going in the right direction. You don’t want to waste resources on something that will not bring any value – to the user or the company. At the same time, while everyone is trying their best to mitigate that risk, be prepared for a situation when most of the feature ideas will have little to no impact on the metrics. This means that you need to try a lot, learn from the failures, and improve over time. Treat features as tests, with hypothesis and ruthless data validation. 

Then we can focus on crystalizing the concept and execution. During this phase the workload consists of, but is not limited to; managing stakeholders,  creating and maintaining tickets, design reviews, UI tests, organising documentation, preparing copy or translations, flowcharts and maintaining information flow in case of dependencies between different teams. Figma is one tool that really grew on me – as the place for design specification, but also a channel for communication between the developers and designers. At the same time it can be easily used to visualise user flows or present early wireframes. Other than that – Confluence, Asana and Jira for documentation and keeping the project running with an overview on the finished user stories.

And again – since you want to validate the impact of the feature, not just ship another thing, treat the release as a start of the test. Some tools can help with that – from in-house baked AB testing frameworks to using 3rd party content management solutions to drive your tests. We have a very nice setup with the mobile team, where we can, with some parts of the app, use Firebase, Contentful and Amplitude to randomize testing variants and create different groups with limited need for dev resources.

What are the biggest challenges you’ve faced and obstacles you’ve overcome as a PM?

Starting with a personal one – I’m a fairly introverted person and public speaking can be quite a stressful experience for me. At the same time driving product requires not only moderating smaller and bigger meetings with stakeholders, but also more public presentations about team vision, failures and successes to people inside and outside the company. The solution for being stressed and overwhelmed was quite easy – do the public presentations very often, push yourself out of your comfort zone, until it’s no longer a problem.

The biggest product challenge that I remember was my first bigger feature release, that was also changing the major functionality of our mobile app. Happy with the user test validations results during the planning phase, after the release happened, we were looking forward to measure the positive impact. The impact was there, sure, but more on the negative side. While current active users seemed unaffected, it was clear that new users are struggling – engagement and retention metrics were going down significantly. 

The good thing was that we had built this new feature having A/B testing framework in mind. It took us about a week to analyze the tracking data and affected users flows, provide hypotheses on how to fix the unwanted behavior and design and ship experiments to gather hard data. In two weeks after the release we could clearly see that some variants were actually outperforming the old implementation in a significant way – so we went with them. To me the real success of this release was not only that we’ve delivered new functionality and value to the user, but that we could identify so quickly that something is going wrong and react swiftly in an impactful way.

What are your favorite ways to learn more about your users?

When it comes to qualitative research I really like going as close as I can to the concierge test – so basically do the user task for them, with prior training when needed, in the natural customer environment. When nicely structured it has most of the pros of normal user interviews but exceeds when it comes to learnings about the everyday user process problems. It adjusts your perspective and adds, in some cases extremely valuable, context of the user environment. I would love to do it more often. I’ve done it previously with photographers and loved the results. 

Other than that – crunching the behavioral data numbers and conversion flow analysis. Properly tracked user behavior can make all of the user problems more visible and the solutions more achievable. 

How often do you run meetings? How do you run it? Does your team run standups?

As a team we’ve embraced and found value in a couple of agile ceremonies. Due to COVID-19 it was also crucial to migrate all of those meetings online, so that we can continue to keep the level of productivity in the times of working from home.

Daily standup with tickets printed and moved on a whiteboard is now a Slack channel with Olaph bot collecting the standup answers. One upside is that it keeps the discussions focused, since we are using the threads on singular Slack messages – the team is not distracted and seems to like this solution.

Every week we are trying to groom our backlog – it’s the perfect way to keep it clean, estimated, and talk about new ideas that we think can be more impactful than projects on our current roadmap. New gen Jira along with Zoom are helping to make that meeting possible and efficient. 

Every week we are hosting a User Insights session, when the data analyst or product people are presenting insights from the recent user interviews, behavioral data analysis or A/B test results. We want to be as data-informed as possible and utilize the whole team when it comes to looking for more detailed problems and solutions. Those User Insights sessions are designed to keep the information flow as wide as possible.

Every 2 weeks, when the sprint is over, we also run a retrospective. It’s very important to gather feedback and react, when something is going wrong – retrospectives are the team’s emotional buffer that generates tangible actionables to fix the behavior we want to mitigate. Our last retrospective was handled in Zoom, the “whiteboard” for the team to put the retrospective notes was done in Miro. To some extent it worked well, but next time we want to try using Figma instead.  

Every 2 weeks we also have the sprint planning session. With the backlog groomed it should be a relatively quick meeting – we discuss the current roadmap, scope and the main goal of the sprint. We start the sprint as soon as the team is happy with the constellation of tickets.

Does your team use OKRs (objectives and key results)?

Our company moved to an OKR driven process about a year ago. We were doing them quarterly, now we are trying to set them per trimester. I believe that, if thought through, they are a very good tool to focus on important initiatives and can be used as a shield to protect you from distractions and team resource mishandling. Especially if you have many cross-functional initiatives. But I think the most important thing that OKRs are helping to popularize, is the idea that the team should not focus on shipping things, but shipping impact. The key result is measurable, so if the team member, mid-quarter, has an idea that everyone thinks is more impactful and easy to do than the current roadmap, OKR enables us, or makes it easier, to just adjust the roadmap. 

How deeply should product people know about marketing strategy, UX design and coding?

I feel that when it comes to Product Management and a needed skill there is only one answer: “It depends, but for sure it will not hurt to know something about it”. Marketing strategy helps to push for better naming, copy, tackling user and business needs, release plans and so on. UX knowledge enables you to have more valuable conversations with designers, produce more focused wireframes, conduct better user interviews. Coding skills will for example help you understand the complexity of development tasks, technical limitations and opportunities, help you to analyze the data, along with more valuable conversations – this time with the devs. All of those skills will help you to create more precise and understandable user stories, conduct more focused and valuable meetings, and set more impactful strategies. All of those skills will help you to be a more valuable part of the team and a better Product Manager. 

Are they absolutely and crucially needed? Not really. But just the fact that you are asking this question means, to some extent and expertise, that they are more than welcome. 

Do you have coding skills?

As I said I was always interested in technology and coding as a way to interact with it. I Coded my final thesis during psychology studies, made two Android apps afterwards to check how hard it is to push something on my phone and to finish post-graduate studies. I then continued with working on automated tests and tasks. All this helped me to better understand my market domain, opportunities and the team needs. I’m not a developer, but I have enough knowledge to appreciate their work.

What skills do you think would be most valuable to learn and prioritize for an aspiring PM with no technical background?

I think that prioritization is one of the key skills and struggles nowadays – managing stakeholders, input from many sources, keeping the vision clear, team focused and inspired.

As the second one I would nominate the skill to conduct research – qualitative, quantitative and being able to analyze the data, find the patterns, identify the problems for the team to take care.

Then it’s time to communicate – within and outside the team, in tickets, documents, product demos or stakeholders updates. You need to be clear, efficient and convincing. 

About Focus

Focus is an OKRs platform that increases team alignment and performance. You can try Focus for using OKRs, running daily standups and weekly retrospectives. This mix of strategy and tactics allows to align the team each day and keeps focus on what really matters. 

The post Jedrzej Kaminski: About skills for PMs, technologies, A/B testing, meetings, and OKRs appeared first on Focus.