Are you ready to hire a Product Owner for your startup?

As you embark on your journey to ask Are you ready to hire a product manager for your startup, where you need to scale the business, grow the company and find the happy path, starting off with clarity, structure and a precise job description is going to provide stronger outcomes for a successful hire of your Product Owner.

Hiring a Product owner for the first time can be daunting! If you're a startup going to scale up, a little tip to think ask first is 'Will I as the founder of the product, be able to trust someone to do a better job than I did' transitioning requires change and change can be scary. If it's a digital transformation role and a product owner is included, a good frame is to ask, does the organization have the basics in place to ensure the PO can work in their chosen methodology, it might mean that you might now even have a development culture or a framework you are using to release software.

What do Product Owners do?

I like to think that the role of a product owner is to be responsible for maximizing the value of the product.

They are great communicators, can be extroverted or introverted. They are effective and clear as glass in translating business talk into talk that engineers understand and most tend to have the decision power and or authority to decide what key features go into the product and be the bridge between business, design & engineering teams.

Do Product Owners have complete authority over the product?

There are many different takes and honestly, I think there are no right or wrong answers, but maybe as a Product Owner, I want to make sure I can still take home a paycheck or get hired. In its truest form Product owners are the single point of contact, they are the 1 person in an organization and they are not really a 'committee' although organizations behave around a Product owner like decisions are a committee, just be upfront about what works for you and your organization.

As naive as that sounds, true product owners are the cream of the crop and an express to c-suite lounge, with the big guns, if they have pure authority and the backbone of business understanding coupled with putting the user front and center and finishing off with the icing of technical speak, it's a talent that few and far companies can aspire to get. They are the ones that are working in the big giants, Amazon, Netflix, Google, Facebook, and so on, but they all got there from different diverse backgrounds, BA related, tech lead-related, design-lead related and even had many points in time where they were just product managers, that started with a company much like yours and team size probably similar with very little ownership, but throughout their career, they received the trust, authority, empowerment, and guidance and they are there where they are today simply because of talent & ownership.

So.. If the Product Owner owns the product, then what do I do?

Product owners a central part of the product it's customers and the organization. That means you need support, buy-in, influence, and great rapport with your peers. The art of managing up is an absolute must-have skill to own.

Many companies have had trouble defining the type of true authority and most companies don't often understand that the product owner simply owns the product no matter who is in the chain of command, sorry in advance if this is blunt, but let's be clear a product can be a part of a feature on a platform and you still have to report to the many different layers of command in a senior product team eg; Head of product, Chief of Product or Group Product owner.

This also doesn't mean that you cannot find a Product owner that has the flexibility, but really think of empowering the product owner or at least ensure that you are defining clear authority levels within your reporting lines.

A story that happened to me,

I once worked at a startup that just closed its Series A, they were on the path from startup to scale up. The founders were amazing, inspirational, positive, motivated, and the people were exceptional especially the business team.

The company was structured remotely, with an asynchronous style of communication and although the relationship started off with all smiles and happiness, it turned really toxic really fasts, smiles became frowns, and being remote you can't hide from the camera!

I constantly felt at every meeting, I didn't own the product and I'm not alone. In a recent virtual conference for product owners, more than 60 participants from Asia and an instructor who was based in the US, made clear points that lack of empowerment in the Product owner role was a contribution to unhappiness at work, its true that the basic design of a Product Owner needs ownership but that's not practical at some organizations, it's shared, a collective and a committee.

It's OKAY, to be this type of company, like I said there is no right or wrong, but it is simply not okay to micromanage, panic on every weekend of progress and it's not ok to specifically 'specify requirements or take screenshots and say I want it like this. Control is hard to give up and accountability being a founder is also difficult to give up, but focus on the business is a 100% full-time role, just like focusing on the product is a 100% full-time role.

So before your hire a product owner and start scaling your team, please define your structure or at least, give the PO and the team the authority to define the structure.

Red Flag 1 - No Scrum no play, there was no scrum or no methodology.

Scrum is a lightweight framework that helps people, teams and organizations, generate value through adaptive solutions for complex problems and Scrum theory is the empiricism of the 3 pillars, transparency, Inspection, Adaptation, Scrum helps organizations focus on improving the product, help teams communicate in person in the office and also remotely, every day during standup.

Red Flag 2 - Micromanagement

Sometimes tickets were just added to the active sprint, because 'we had to do it, the boss said so. If you're the type of founder or you work in the team that has this input, it's important to make it clear to the hire that is part of the company's successful culture. Some business cultures in Asia rely on micromanagement in everything they do and are siloed or pyramids with a paternalistic way of management, it works, they are billion-dollar companies and it's a way of life for them. But please define the lines of authority and sign-off, the worst thing is a newly hired Product owner who exercises decision power, that gets shot down.

Red Flag 3 - Hubris

"I've been in buisness for 25 years I know what my customers want"

Oh red flag, be open. You might have the experience and season, but we are only just 1 person and we don't represent all customers from all walks of life. So, be open to someone else telling you about what the customer wants and the user's pain points or gains. Learn and unclear, if the culture at your company is that you do things a certain way, and you're not open, then rethink the role of a product owner and just get a project manager with BI skills, it could just be what you want and need.

Don't fall for the Hubris

'At no point as a leader that you would be arrogant enough to know everything about your product or your customer'

Red Flag 4 - Cutting Corners leads to tremendous technical debt.

Ok so scaling up we need to cut corners, sometimes the need to A/B test features, landing pages, or functions helps iterate and come up with a final decision on what goes into the product when we apply methods of design thinking into the mix of a product owner's priority roadmap. But Cutting corners is speedy, yet dangerous, I once worked with a founder that would let their developers and themselves change to add stuff in the database, enums no big deal, at any point of time, fields of customer data would break, a comma here and a something there it's a needle in a haystack if you cut corners and it leads to terrible outcomes.

I'm not saying cutting corners is bad, it's good for certain initiatives but it's really bad for others, so if you are at a place where scaling up your startup has been messy and the board is full of technical cards of debt, maybe now is not the right time for hiring a Product owner, maybe now is the right time to hire a Head of Engineer, Security Ops, more developers to just get all this stuff refactored, nicely packaged and artifact in place.

No Product owner should work on bugs from the past, on hot potatoes, it's painful and unexpectedly part of the job, but really decide on what kind of responsibility they have if 50% of their time is going into translating edge cases that just doesn't happen and usability or logic issues that are not bugs found by customers but found by you, are you moving the product meter, the question to always remind yourself is 'What is the opportunity cost, if I work less on this and more on that.."

Being nimble are the trades of everyday work and there is an amount of technical debt that starts to accumulate over time and within each release, whether refactoring is required, or more maintenance, there needs to be a balance in quality assurance and product exciters.

'Cutting corners accumulated so much of technical debt measured more than a balanced amount of 'gains, pains and jobs-to-be-done, that the company will spend more money to reduce the pain then to conduct the pleasure'

Red Flag 4 - Teamwork

Implementing your first framework for development or employing the start of your engineering team with a few developers, it's a great imperative to decide what kind of methodology do you want to employ, if the waterfall is important for you and your clients as an agency or if you're a consumer/business-facing application still trying to find product-market fit, maybe agile could be the winner.

Agile practices is not an individual sport, yet individual contribution is really important and Agile practitioners will argue that the defined structure of the team and how it operates in an Agile environment is important, although teams are fully functional to adopt Agile and may succeed, don't misunderstand that people are people and people tend to have individualistic needs, not all people work the same either, so in the collective group made up of individuals, everyone must contribute and if they don't then, that's something that needs open dialogue, rather than closed.

Agile and even waterfall in its core is a team sport a 'We sport'. Getting downstream requirements and upstream of initiatives is an everyday plight for a product owner, so whatever method you employ, be honest about the level of teamwork the role involves.

If your team are a bunch of individuals that say "I" rather than "We" there's going to be some rough weather, so Scrum is a good start and there is no better way than starting scrum by just implementing one part of the methodology which is the retrospectives, start from the end and focus on the 'let's discuss when went well during this release if you don't have sprints yet' and if teams need to be brought together, ice-breaking with the therapeutic elements of a retrospective with engineers is a great starting point, you can opt to do demos or even planning next or jump in and fully go into the scrum, but lead the change, adopt a method and find something works for you, later on, you can evolve your methods and address not only retrospectives and what went well but even slot in breaks in between sprints where openness on challenging the status quo, of your systems, processes, logic, and designs can be entered upon, Scrum is a guideline and a very good one, but blindly following scrum to tee, can lead to things that are unforeseen where dialogue outside the scrum structure is required at times to fundamentally hit that continuous improvement goal.

Now let's decide together what are the Pros & Cons of the Role, as a founder, how do you trust your baby with a stranger?

Use the six-thinking hat to help you decide what you think you want out of the hire as a founder or business owner, remember as candidates on the lookout to switch roles, we want to believe and we want to be empowered and inspired by you, so the decision is key and reminding you that the decision you will finalize to stick to it. With all scale-up teams, it comes with pains and gains, but that's the beauty of big organization and efficiency, structure.

So try it out see if you believe it's time for the next phase in hiring a product owner to help you execute your vision.

Six Thinking Hat

As a founder or business owner, it's important to establish and identify the 'Why' do you need a Product owner, here is a quick easy exercise six-thinking hat principle to help make your decision easier.

White hat

What are the facts of why you need this role?

"Slow product releases, skills gaps, focusing on bringing new customers/clients"

Whatever the reason, you must establish the facts, for why you want this role.

Red Hat

How do I feel about hiring a product owner?

"Relief, Excitement and organized"

Yellow Hat

What are benefits does this role provide to me, my team, and my organization?

"Faster release, fill the skill gaps, provide formal structure, learnings'

Green Hat

What kind of creativity will a product manager bring to the table?

" usually features a.. feature b.. features c.. we can be x.."

Blue Hat

What do we need to get this role?

"Create the organization chart, distribute this to your team and present the new role and the responsibilities, clearly define the KPI's and goals of how this person is able to succeed in the job for it to make a difference ."

Help your newly hired Product Owner integrate and adjust well with the team, praise works.

Before appointing the owner of the product, create a vote or get behind it, if your team is hesitant to move into the structure, or lacks experience in practicing agile, it is up to you to encourage and install habits of agile. We all need to learn, adapt and grow a bit. So don't be afraid, do it, and 6 months down the line, they will thank you for it.

Take yourself out of the equation, the product will not suffer!

With the right discipline and training, a true product owner is one that listens to customers, acts on the quantitative data of user interactions and the measurement of success for a product owner is never getting the product into a decline and one that takes your guidance, advice, and mentorship seriously.

Product owners are the ones that are forever making sure that your product stays relevant and competitive by transparency, inspections, and adaptations, when you trust the right type of talent and find the ideal candidate that fits within your business, there will only be upsides to your growth. Look forward to the discoveries made by teams with Product owners and their ways to delight the customers. When you have happy people and happy customers, you have a happy business.

Don't forget you're the inspiring figurehead, your goals are different from the product owner's goals and at a high level they sync up with your business strategy, speaking with your vision will help foster creativity and innovative solutions from product owners, so take the time to provide business context on what is important strategically, what's going to move the meter and what is a delight to your customer.