What are some Product Management OKR examples and why do you need to set them? Product is probably the most important function in your company. Together with Sales and Marketing they are the ones that make sure the hard earned money you invest in them is delivering the maximum value to your business. This means that a focused Product Team can be the pilot who adjusts the engines (your engineering team) on the rocket-ship you call a company. But this also means that every effort that is not spent on delivering on the main objectives for the company will be a loss multiple times over, loss of the effort put in, and a loss of the opportunity cost of something better that it could have been spent on. OKRs are a great way to get your Product Team focused, but how is it done?

Throughout our content at Focus we are referring to functions with capital letters, such as Product, Sales, Customer Service, etc. When we don’t use the capitalized version, we mean the thing being built. Psst, are you in Marketing? We have 21 OKR examples for you too ?

What is Product Management?

Why are we talking about this in a post that’s about how to set OKRs for Product Teams? We are talking about it because Product is a nebulous, nascent and often misunderstood field. This can lead to the whole OKR thing going sideways for unfortunate Product folk even before the first O is set. So, what is Product Management? Let’s take a step back and see Product within the Scrum framework:

Scrum (n): “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”

Scrum Guide November 2017 version

I highlighted the part about value because at its simplest form, that is what Product Management is about. Are you a Portfolio Manager, Product Manager, Product Owner, Business Analyst or god forbid a Project Manager doing Product stuff at an organization that doesn’t understand the role? First of all, make them listen to Marty Cagen and explain to them that your daily activities should be tied to maximizing value to users and, consequently, to the business.

Product Team OKR examples

Cool, why don’t we just set this as our main objective? Not so fast. Product Management is also about finding the balance in delivering this value. Could you deliver outstanding value today by ignoring technical debt? Sure, you could. But what about tomorrow? Could you only focus on your users and shut your internal stakeholders up? Sure, but your relationships would suffer and you couldn’t effectively lead without authority, one of the hallmarks of any good Product Manager.

With this is mind, let’s group some of the activities a Product person does at a company. Since Product can take many different forms and different companies, this list by no means will be exhaustive, but let’s give it a shot. If you have ideas or feedback, do get in touch via the chat bubble on the bottom right.

Let’s group Product Management and Product Owner activities into 4 large areas. Sometimes it’s one person dealing with all of them vertically, sometimes the responsibilities are split between strategic and tactical, so pick accordingly.

• Vision and strategy
• Ideation, alignment, validation, prioritization
• Build, measure, learn
• Release and grow

Let’s break these 4 big areas down into smaller ones and let’s look at some examples. You should only select 3-4 OKRs per quarter per team, so don’t think that you need to have as many OKRs as we have in our examples here. Identify what area needs improvement the most and formulate your powerful OKRs to support you and your team.

Vision and strategy

Without a bold and clear vision and a killer strategy, it will be difficult to prioritize and ultimately deliver maximum value to your customers and the company. What OKRs can help focus your efforts when it comes to vision and strategy? Let’s look at some themes and OKR examples.

Domain knowledge

Objective: We have so much awareness on our competitors that we can sell their product better than they can
Key results:
– Talk to 10 customers who have switched to a competitor
– 8 out of 12 of the Sales Team members can name our top 5 competitive advantages
– Increase the number of new users who switched from a competitor from 5% to 15%

Objective: Become the champion ti the customer
Key Results:
– Conduct interviews with at least 40 of the top 100 customers
– 80% of people in the company can name at least 3 out of our 5 user personas
– Reduce churn rate from 20% to 12%
– Increase NPS (Net Promoter Score) from 47 to 65 
 

Share the mindset

Objective: Everyone at the company should share our awesome vision
Key Results:
– 50 out of 65 of our employees should accurately recite our vision and mission statement
– Reduce vertical feature requests from 5 per month to 1
– Increase eNPS (Employee Net Promoter Score) from 35 to 70
– Time spent in meetings remains an average 8 hours per week for each employee

Objective: Make the Jobs-To-Be-Done approach a core skill for everyone
Key Results:
– 9 out of 10 user stories submitted by sales have a well formulated user story
– 2 out of 10 feature requests can be solved without building new features
– Increase day 30 retention from 65% to 85% 

Turn vision into strategy into roadmap

Objective: Create a culture where metrics and data drive our business and product decisions
Key Results:
– 8 out of 10 user stories have success metrics defined and evaluated after release
– 4 out of 10 user stories have a projected business value attached to them
– New feature adoption is at a minimum of 60%
– Marketing investment on feature launches remains stable at 4 hours per feature launched

Objective: Be radically ahead with your backlog
Key Results:
– There are 4 times as many written user stories in the backlog as stories on a sprint
– There are estimated tickets for the next two sprints - average storypoint: 85 

Ideation, alignment, validation, prioritization

You can be the best PM in the world with the most contacts, stellar industry knowledge, and a time machine. You still will fail if you don’t rally the company around coming up with new ideas, aligning on what to do, why, and in what order of priority.

Empower to ideate

Objective: Make stakeholders the center of the ideation process
Key Results:
– 4 out of 10 completed user stories came directly from stakeholders
– Increase eNPS (Employee Net Promoter Score) for the sales team from 32 to 55
– Increase the demo to sign-up conversion rate from 30% to 60%

Align team and stakeholders

Objective: Delightfully transparent and radically aligned prioritization
Key Results:
– 0 sprints are affected by mid-sprint critical priority items
– Stakeholders rate the transparency of the prioritization process with at least 4 out of 5
– Complaints about prioritization come up only at most on 3 retrospectives out of 10
– New feature adoption is at least 40% 

Build, measure, learn

This is the mantra of a well tuned Scrum Team. After the team, together, with the stakeholders has identified problems to solve, created user stories, refined and estimated them, they are ready to be taken into a sprint. 

Seamless maker time

Objective: Create a blissful work environment for the scrum team
Key Results:
– Sprint goal is delivered 8 times out of 10
– Zero new stories are taken into the sprint after it has been started
– Story points delivered each sprint can increase from 45 to 55 

Build with quality

Objective: Deliver a delightfully smooth customer experience while shipping more
Key Results:
– Maximum 2 critical bugs are reported by customers per sprint
– NPS score stays 65 or increases
– Story points delivered per sprint stay flat at 45 or increases 

Measure what matters

Objective: Switch from gut feeling product decisions to being radically data driven to reduce complexity
Key Results:
– Every user story has success metrics attached to it
– Increase eNPS score for the Sales and Customer Service teams from 40 to 65
– No new feature with less than 40% adaption rate remains live by the end of the quarter 

Iterate with confidence

Objective: Bring maximum value to customers with the least amount of investment
Key Results: 
– Every feature must have an MVP version and at least 1 iteration
– No feature shall be delivered over multiple sprints
– Increase NPS score from 65 to 75 

Release and grow

You have identified your customers’ pain points, devised and validated a solution, broken it down to manageable iterations and built it, feels good, right? Don’t want to discourage you, but if you botch the release even the best feature or improvement can fall flat and fail to gain adoption, ultimately not contributing to the most important measure most companies have, growth.

Release smoothly

Objective: Achieve magical CI/CD (Continuous Integration / Continuous Delivery)
Key Results:
– Increase number of releases from 4 per quarter to 16
– Reduce complaints on retrospectives about deployments from an of average 2 to 0.5
– Keep number of critical bugs reported by customers below 2 per release

Objective: When we release, our customers can’t help but be impressed
Key Results:
– Increase NPS from 45 to 75
– Increase average first month feature adoption by customers from 30% to 65%
– Maintain newsletter unsubscribe rate in line with the current 6%
– Maintain average product related customer service conversations at 34 a day 

Product Management OKR examples to grow

This is where all the AARRR metrics (Acquisition, Activation, Retention, Referral, Revenue) come into place and where having well implemented analytics is crucial. Don’t worry, a bit further below we’ll give you examples on what to track if you only have limited analytics capabilities. AARRR metrics make for some of the most impactful Product Management OKR examples.

Objective: Convert more visitors, simple as that
Key Results:
– Increase demo signups by 20%
– Increase demo conversion rate to signup by 10%
– Increase self serve signup from 5% to 20%
– Keep cost of a demo booked below $45

Objective: Make a radically smooth user onboarding and activation experience
Key Results:
– Reduce churn through onboarding funnel steps 3 and 4 from 60% to 20%
– Reduce time to wow moment (setting up first OKR) from 4 days to 1 day
– Increase profile completion rate from 20% to 85%
– Increase NPS score from 55 to 75

Objective: Achieve stickiness
Key Results:
– Increase day 30 retention from 30% to 75%
– Increase weekly frequency of usage from once a week to three times a week
– Increase free to paid plan upgrade rate from 5% to 15%
– Keep Customer Success time invested per free user flat

Objective: Spin up the referral flywheel
Key Results:
– Increase customer acquisition through referrals from 0 to 0.2 per existing customer
– Maintain 30% churn for referral cohort, in line with sales acquired 
– Don’t let LTV (Lifetime Value) drop below $50 from $75


Objective: Achieve sustainable profitability
Key Results:
– Reduce customer acquisition cost from $150 to $75
– Increase LTV (Lifetime Value) from $50 to $100
– Reduce churn from 75% to 30%

Objective: Shut_up_and_take_my_money.gif (Increase cash flow)
Key Results:
– Increase value of yearly payments from $130k to $300k
– Increase number of large accounts (50+ seats) from 8 to 25
– Increase free to paid plan conversation rate from 15% to 30%
– Maintain free plan churn at 45%  

Product Management OKR examples when you have limited data

A key tenet of OKRs is that KRs need to be measurable. This assumes you have done the necessary groundwork and have readily available, reliable data. But what if that’s not the case in your organization? A lot of small companies don’t invest in data in the beginning. And I’ve seen even bigger, post Series A companies where data just wasn’t there. Sounds familiar? Don’t worry, there is a lot of data you can get even out of a simple Google Analytics implementation to your website and asking devs to help you with some database queries once in a while. And there is data you can gather just by sending out a simple Google Forms.

Objective: Convert more visitors, simple as that
Key Results:
– Increase time spent on page from 30 seconds to 2 minutes
– Increase number of pages viewed per visit from 1.1 to 2.1
– Increase number of of visitors who sign up for free trial (visitors vs new free users) from 5% to 15%

Objective: Make a radically smooth user onboarding and activation experience
Key Results:
– Reduce steps to wow moment (when customers said in research they definitely will keep using the product) from 12 to 6
– Increase activated users (one who created a check-in) from 10% to 40%
– Increase proportion of users with a profile picture from 30% to 80%

Objective: Make our product well known and well liked
Key Results:
– Increase NPS score from 55 to 75
– Add 200 reviews on Capterra
– Increase average review score on Capterra from 4.1 to 4.6 

Product Management OKRs are Scrum Team OKRs

I’m a big proponent of Scrum Teams having one set of OKRs on a team level. If it’s your first time doing OKRs, it’s probably best to only set them at a team level anyway. This way you can avoid one of the biggest mistakes -having conflicting OKRs.

You should still assign one person to be the lead on the OKR itself though. It is logical to choose your Scrum Master or Product Owner as the lead, but if you want to instill a bit more outcome driven thinking, ask a developer to volunteer.

All right, but how does a Scrum Team OKR look like? In a healthy company, each Scrum Team has a single Product they are responsible for or a group of features within a more complex Product. This makes it pretty simple to pick a set of OKRs as usually you have a clear idea of what makes the Product or feature set successful for the given period. And you can use the examples we shared above and tweak them to fit your team.

Get focused

Having great OKRs set up is only a piece of the puzzle. What is more challenging is keeping the team focused on their objectives day after day, sprint after sprint. This is why we developed Focus, where you can set your OKRs up, but instead of forgetting about them until the next quarter, we devised a solution that can help your team stay on top of them. We incorporated OKRs into daily and weekly check-in rituals. They take no more than 2 minutes a day but the result is a team who knows what they are working on that day is moving the needle. Reduce useless work, drive motivation by clarifying purpose and reach the maximum potential of your team. Check out focus and use some these Product Management OKR examples to get started.

The post 23 OKR examples for Product Managers 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.