Product Ownership – Resources

I started out less than ten months ago as a Product Owner, with life made a little more interesting that I was working across 2 products and 4 (remote) teams. Over the course of the next few months, this expanded somehow to 3 products and 9 (remote) teams! I’m very very pleased to report that when I return to work next month, I will be down to one single (significant) product and four teams – ok, still remote 😦

The upshot of these challenges was that I had a lot to learn in my new role, and I would like to acknowledge the resources I used along my growth journey to help me. These helped my clarify my role, focus on the key things I needed to do, and most importantly, develop the right mindset to be a good Product Owner. These key people have been my ‘virtual mentors‘ and I’m super-grateful to them for the wonderful work they do sharing their knowledge and insights to everyone.

Roman Pichler:

A great overview, as well as lots of in-depth articles on Product Ownership

An equally informative view of Product Management, the framework and how it fits in with Product Ownership with Agile in large organizations.

Intercom – Des Traynor:

Great blogs on Product Strategy, some fantastic free books to download, and every re-read yields a new gem. When I grow up, I wanna be like Des Traynor. 🙂


One of my best finds of the year – a community of people writing about everything under the sun. Some great articles on Product Ownership, but you will need to find them under the general Product Management Category.

Product Talk – Teresa Torres

Teresa focuses on the hows and whys of building the right thing, and has inspired me to think about how to apply user-centred thinking and design when breaking down themes into Epics and Stories.

Jeff Patton

I held out for months so I could attend Jeff’s Passionate Product Owner Training, and it was worth it. Every minute was riveting, one of the best courses I have EVER been on, and I learned so, so much. I’m a finicky so and so but the ONLY thing I had to bitch about was the food (which was done by someone else). Life’s hard! 🙂

As a starting point, read this massive, super-informative post packed with ideas, techniques and tips.

Other Resources:

While the above were my “Go-to” blogs, there have been a few other websites that have been great to dip into from time to time.

The Unbreakable PO – hasn’t been updated for a while, but some good classic techniques and tips.

Crisp’s Blog – Henrik Kniberg’s blog – All things Agile, but some great PO focused posts.

Finally, a MUST-WATCH video that you can point people to when they ask what a Product Owner does – thanks to Spotify for this gem. I prefer reading over videos any day – but this one is a GEM!

Do you have any other awesome PO resources to share? I’d appreciate trying something new, I’m always learning!

What an Agile BA must do differently to succeed

This post was originally written for the Agile Australia blog

Stepping into a BA role in an Agile team can be quite confronting when you consider how much Agile downplays and minimizes the BA role. But be assured, you have an important part to play, and it’s actually way more fun to be an Agile BA.

To successfully make the transition into Agility, there are four key things a BA must do differently.

Embrace your role in the cross-functional team


YOU are the person who best understands the business problem, right? So you’re the best person to know when the problem has been solved. Help the team understand what the 80% business scenarios are for targeted automation testing. Write test conditions to ensure that the team have a shared understanding of the solution.


Apply your understanding of users and stakeholders to ensure that documentation is written for appropriate audiences – users have simple workflow information and administrative users have the detail they need.

Conquer the cone of uncertainty

The feedback loop is your friend. The pressure is no longer on to get everything scoped and signed off at the very start with 100% perfect requirements. Start with the big picture, break down chunks, and only delve into the detail for specific areas as the need arises, or you gain further insight into problems.

Inspect and Adapt

One of the great things about Agile is that you’re not expected to build the perfect solution right away. The framework allows you to try the easiest and simplest solutions, understand where and why the solution is inadequate, and what needs to be done next.

Enjoy the ongoing engagement with stakeholders

Because you are delivering solutions in slices, it’s easier to run demos and workshops by iteratively demonstrating progress, and looking for the point when a solution is good enough. This is a great way to build confidence and trust with users and stakeholders, and to collaboratively look for usability data to drive decisions of what to build next.

Agile makes it easier to build the right thing, and achieve maximum customer value whilst minimizing effort. The process of uncovering the right requirements becomes much easier, with less frustration over work that didn’t achieve the desired outcome – and ultimately, far greater satisfaction with a job well done.

Three months in as a Product Owner

It’s….. been a busy few months!


Product One – Coordinate the backlog and sprint planning across 1 experienced team in Christchurch (where I’m based) and 2 new teams in Auckland. Make sure the experienced team (doing the bulk of the work) have enough to keep them working on a large focused customer delivery. In addition, the two new teams need well defined, small but independent stories that will help them learn the code and domain, and enable to start contributing value to the product.

Product Two – Having just taken over this team in Canberra and with no depth of experience in the domain, I have focused on getting good processes and touchpoints between the team and me established. I am leaning heavily on my Product Manager who is the Domain Guru to help, and we have got one release out, completed Release Planning for the next one, and with ongoing regular contact, the team continues to perform well remotely

Product Three – Another new team in Canberra, with a different Product Manager, significantly different domain, and significantly different style of working. Once again I am focusing on learning the team’s operating style, and getting our processes ironed out. The focus with this team, and a relatively new product, is to really understand the main use cases and try to stop going down the rabbit-hole of edge cases so we can take a viable product to market ASAP. A lot of our process refresher discussions and Release Planning has focused on this.


All the teams are great, accepting of the changes and enthusiastic and positive about working together.

We’ve had some great SCRUM / Process discussion sessions and are on the same page about how we want to work.

Our structured Release Planning and backlog grooming sessions have been great, and teams appear to be happy with the process leading to a clear and defined scope and target date – which hasn’t always been consistent.


It’s hard to ask the right questions and uncover the areas that are critical v/s not when you don’t know very much about a domain area – and of course this domain is so complex, with lots of clinical risk. However this is going to be a critical skill and I need to learn how to do this – fast!

It’s difficult to work with remote teams, and much more so when the people on both sides are new. We’re still working out what each of the individuals are like, what each of us want, how we work, and it’s exponentially harder remotely because you can’t read facial expressions or body language over Skype chat. You could get left out of key conversations or miss little details because you’re not listening to the little chats going on, and they often forget to loop you in – or don’t think it’s worth asking about. A couple of times, even with discussions, people have finished up a conversation with some people thinking a different decision was reached than others.

Expectation Management!  Frankly, it’s difficult when Product Managers (who are so influential in what is done, and how the team works) work so differently. One (who has a number of products in their portfolio) is happy to provide general direction and guidance, check in regularly and give you lots of autonomy and background information to stories, and access to clients and stakeholders to understand the business value. Another (who has just one product and therefore more time) prefers to be a lot more hands on, will work with UX and Technical leads to fully develop the user story and all artefacts, and just present it to the team as “Build this” and resists sharing information about context, background, or users. You can guess which one I find more inspiring! 😉

All in all it’s been a huge learning curve, but oh boy is it busy and stressful! I’m hoping that in the next 3 months, things will settle down and standardise and it won’t feel quite like the never ending race anymore!


Lessons learned as a new Product Owner

I knew I wasn’t signing up for an easy gig. Moving from Business Analyst to Product Ownership meant a significant shift in my roles and responsibilities anyway. Being a Product Owner for 3 products and four remote teams right from the get go, without any real domain experience to help, was always going to be a challenge. It’s a good thing I’m too stubborn to be scared of anything like that!

This isn’t the story of a miracle or the happy ending of a movie. Things haven’t fallen into place like magic. I’m still learning, I’m still struggling, but I know I’m going in the right direction. Here are the three biggest things I’ve learned, though.

Working with remote teams is HARD

I always knew this one was going to be problematic. It’s difficult not being a part of impromptu conversations and questions, and communicating by Skype chat or video with a large team means you miss a lot of non-verbal communication. I do travel to do important stuff like Release Planning face to face, but that is once every 2 months, and it’s not really enough to build strong bonds with teams.

I’m still working out how to get better at this but one thing I have learnt is that the teams where the team leads are proactive and will always be thinking about when they need to loop me in produce much better outcomes than teams where they don’t. If you figure out how to do this better, please help me!

Standardize Processes as much as possible

Make sure everyone understands roles and responsibilities clearly, and who to involve when. This goes a long way towards helping people decide when to reach out vs when to solve the problem themselves.  And try to ensure that your processes are similar for each team and product – because the difficulties arise when you’re trying to do things differently for each – the stress of remembering to do the ‘right’ thing for that team or product is more.

Don’t be afraid to ask for Help

Change is hard, and people resist it. With no direct authority, not being co-located, and without the deep domain knowledge that the team can turn to you for, it’s difficult for them to see the value in the Product Owner role. The Product Managers and Development Managers have been fantastic in impressing on the teams that this is an essential ingredient of creating good software and they have stepped in and reinforced this. When I can’t be there, the team leads have been fantastic ‘eyes and ears’ for me and have given me so much valuable advice on how their teams work, how to achieve a particular outcome or what to watch out for. I’m lucky to have some great people helping me – and all I had to do was ask!

I know that we’re past the forming stage, and I’m wondering if/ how storming will happen – and hoping to get to norming ASAP… watch this space 🙂

BA to Product Owner

I’m shifting gears a little bit with this post. I’ve been a BA for a fair few years now. I’ve worked not just in development teams creating software, but also on projects controlling scope and quality, and with clients facilitating process analysis and future state planning. Today, I’m a senior BA in a fantastic company that is taking on the world in it’s industry, in markets across the world. It’s been an exciting, stimulating and challenging year getting up to speed in a new industry. And I’m extra excited today because tomorrow, I get to start a new role doing even more super exciting stuff.

Scaling Agile

A little bit of back ground, for context. The company I work with has some amazing product managers. They know their domain, they understand their markets and customers and work closely with sales and marketing to make things happen commercially. They are also expected to be providing input to the development team as Product Owners by creating and maintaining product backlogs, ensuring that stories are well written and understood by the team and generally being responsible for building the right thing. This may have been the ideal a few years ago, but since then, the company has grown. Development teams are located in 3 different cities for the same solution suite. Sales and Marketing demands have grown immensely. And as the scope of work has expanded, even super-awesome product managers are struggling to fulfill all aspects of their role.

We needed do find a way to let Product Managers do what they are great at, and what only they can do, and take the other stuff into another role.

The Plan for Product Ownership

While the Product Managers still own the Product Vision, Road-map, and all commercial and strategic decisions related to the product suites, the Product Owner role helps translate the vision and road-map into smaller, prioritised stories and features and keeps the development team building the right thing.

While the Product Manager is very much an outward facing role, the Product Owner role is far more inward facing. The goal of the role is to ensure that the Product Manager’s Road-map is translated into a DEEP backlog, and it is sufficiently well defined and articulated for Development teams to start work on. The role focuses on Building the Right Thing, so that the Development Team can Build the Thing Right.

What happens next?

As a senior BA, I’ve been doing a significant chunk of the ‘expected tasks’ in the Product Owner role, including keeping the backlog up to date, collaborating with Product Managers to do Release Planning, ensuring that the team understand the Business Value of features they are building and generally ensuring that we are building the right thing.

From here on I get to do a lot of these officially as a Product Owner, not just for my team but rather for the entire product suite – currently about 4 products in active development. I get to work with our Product Managers and Development Directors to figure out what our goals are, what success looks like and (once I have finished having a nervous breakdown), figure out how we’re going to get there.

But I have a secret weapon – I can depend on the solid, unwavering support of my Tribe Lead who is also undertaking this journey with me!

And I look forward to telling you all about my plans for PO domination (and what the heck is a Tribe anyway) soon!

Business Analyst to Agile Team Member – the beginning

I’m rocking this BA gig!

Some time in the past: So I’ve been a BA for a couple of years now, I’ve got my head around all the different types of specifications we write for different types of features. We’re talking documents where the basic template (with no information filled in) runs to 15-20 pages. I’ve learnt to add every piece of information possibly relevant into the document, because otherwise, the developers and testers will tear it apart at the walk-through. So in other words, I’m doing a stellar job as a BA and I have been encouraged and rewarded for this at suitable moments by the company I work for.

Side note: Yeah I can say with hindsight (20/20, yo!) that what was adjudged a stellar job for a BA in that workplace is so far away to the standard I have in mind today. And it makes me weep when I see BAs doing all those things I used to, when I didn’t know any better.

We’re going to be adopting “Agile”

Picture this: The room is full of staff that have ‘gathered around’ on the development floor. An announcement is imminent if not highly anticipated – we’re going to be restructuring development (yes, again). And yes, the anticipated restructure is indeed happening, but this time, there is a new flavour in the mix, and it’s called AGILE.

Everyone rushes back to their desks and starts searching. I’d say googling, but this was a while ago, we could have been Yahoo!ing for all I recall. The overwhelming result seems to be one exemplified by the classic Dilbert strip.

Dilbert Agile

Obviously, management had decided that we were no longer panicking enough when restructures were announced, and they had to really up their game.

Actually, you don’t fit in

Okay, confession time: I love change. I embrace change heartily, and even my self-involved narcissist had realised that restructure after restructure meant that management was trying to fix a problem, even if I didn’t know what the problem was. So of course I was jumping up and down in glee, and delighting in the information that we’d be learning lots of new stuff and trying new processes. Then I made the mistake of trying to figure out how I could be a kick-ass BA in the Agile world. Boy, was I in for a shock.

Apparently, there was no such thing as a BA in Agile or SCRUM.

There was article after article in the Agile realm that made it clear that the BA role was overrated, and would be shared by Product Owners and developers in the new Agile world. No documentation was needed, the team shared all the analysis tasks and no detailed upfront analysis was even required before starting stories.

You need to do analysis, but that doesn’t imply that you need analysts.

Well, I guess I was stuffed! I was the youngest and most inexperienced BA in the team – no where near PO material. And as for being developer material…. (unending chorus of laughter).

Suffice to say, a couple of days of reading over the weekend left me neither enthused about the change, nor particularly clear about what the changes would actually mean, and suddenly I was wondering if change was always something to be excited about.


It all worked out in the end. I made the transition, and I am LOVING the Agile/ SCRUM frameworks. I wrote a bit about the difference in the roles here:


What does a BA do?


If you look for the definition of a Business Analyst, you’ll come away with lots of words in your head. If you come away with a clear understanding of what a BA does, you’re far cleverer than I am – reading some of these definitions left (the non-BA) me none the wiser. The established authority in this field, the IIBA, describes the role as “a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”

It’s ironic that for a profession that is supposed to be the beacon for clear and concise communication finds it so hard to explain in simple language what it does. And let’s face it, I’m not going to tread where loads of experts have gone before. Let’s face it, once you have a few years under your belt, you’ll not only understand these definitions, you’ll probably think they’re pretty good.

But what I could do is lay out what I do as a BA and that could be a starting point if the context makes sense to you.


I’ve only ever worked as a BA in companies that develop and implement software. I can tell you what I did as a typical BA in a development or implementation team does in these companies. However, not all companies are the same, not all teams do the same things, and no two BAs work exactly alike – so you’ll need to find your own flavour of BA for your own special set of circumstances.

What I do as a BA

If you’re reading about BA stuff, you’ve probably encountered the ‘five Ws‘ and ‘five whys‘ already. If you’re doing BA type work in any capacity, you’ll know that people always tell you WHAT first, not WHY – even though the latter is what you actually need to know first. So lets do the BA thing and start with the WHY, not the WHAT or HOW.

Why: My team needs to build the right thing, so that we can maximize our value to our business, and minimize the work not done.

The company that you work for has a product or solution that needs to satisfy a business need of current and future customers. Your team is employed to build or implement something that increases the business value of the product or solution, usually within a set of time constraints. According to the iron triangle, you have budgeted resources (your team), you have a schedule (the next release date, or project completion date), and you have the scope of the work for the project.

Because your budget and schedule are (generally) inflexible, the only variable is scope. It is absolutely essential to the success of the product or project that this scope is well managed.

– If you try to do too much with the allocated time and resources, you won’t finish in time.

– If you don’t do enough to satisfy the business value of the product, or the business needs of customers, your work is wasted.

Which brings us to:

What: The BA needs to find that delicate balance between what will satisfy the business needs of the customers whilst being careful to ensure that time or budget isn’t wasted building ‘extras’ that aren’t essential to the success of the product.

It’s that easy. Sounds simple, doesn’t it? It actually is. You’ll just need to figure out exactly what you are building… and why.