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.

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 🙂

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.

Starting out

A complete shock

10 years ago, something ridiculous happened to me. I found out I was pregnant.

At this point, I’d been with my partner for 2 years, we were planning a wedding, but essentially living the party lifestyle. We both had jobs, a wide circle of friends and an active an varied life that just happened to involve lots of parties and catch-ups and barbecues. We were certainly not planning to have a baby, especially RIGHT NOW, and were a bit traumatized at the situation.

A changed life

To cut a long story short, having our son was the best thing we could have ever done. Having a baby forced us to do things wayyyy differently than we had planned.

Zain born

– We decided to get married right away rather than wait the year we had originally planned. We brought the date forward 6 months, booked the first venue we found (in the city that his parents lived in) and had a amazing, no-time-to-stress wedding.

– We decided to move to the city we got married in because we wanted to buy a house and have a family orientated lifestyle, which was a LOT harder in the huge city we were living in at the time

– David had to retrain in a different field because there was NO WORK AT ALL in his industry. His years of experience at being an awesome sound engineer in the best studio in the country didn’t count at all.

– I gave up my awesome job and prepared to be an at-home mom for the first year or 2 of our son’s life. That only lasted 6 months – when he turned 8 months, I went to work in yet another role in software support – something I had done for the last 7 years in various capacities.

Some of this was good, and some of it was not so good, but the sum total of all these changes meant that we went mentally from being good-time party animals to responsible parents in just over a year. And THAT was an amazing thing to happen.


Learning to be a responsible adult

When I started work again, I resolved to focus on my work and career rather than treat it as a necessary evil that paid for my social life. I started actively figuring out how I could be a better employee, and what I needed if wanted to move to the next rung of the ladder. I researched tools and techniques and courses, and read stuff online. And incredibly, I struck lucky. Within a few months, I moved from my entry level position to a team leadish role.

But I wanted more. Now that I was reading stuff and learning new concepts and ideas, I wanted to do more. I put a little bit of thought into what someone with my skills and interests (and technical limitations!) could do. And at some point I decided – I’d make a kick-ass BA.

What I thought makes a good BA

– Knowing a little about the domain

– Knowing a little more about how our customers use the product

– Knowing a lot about the product

I’ll talk about how that  worked out for me in a future post. Right now, I want to talk a bit more about what I did next.

How I got into the BA role

I was lucky to work in a company where there were loads of opportunities for staff to mingle, like end of month drinks or staff starting & leaving morning teas. I used this time to chat to people who were BAs to figure out what each of them did, what they liked about their role and what they thought would be useful skills for a new BA to have. I talked to the BA and development managers to understand what they would expect a BA to do and what they would look for if they were hiring someone for the role.

I went online and looked at similar jobs, and found books at the library that might help. This was a while ago and there weren’t quite as many resources online as there are today, and to be honest I didn’t have enough context or knowledge to fully understand a lot of what I was reading.

Once I was confident enough that I was a decent match for some of this stuff, I made sure I expressed my interest in learning to be a BA to people in the area. I got a few tips on what to do next, and made sure I followed up on these.

– I started reading legislation and policy documents relevant to our domain which was a key component of the role.

– I learned how to do BPMN and workflow diagrams.

– As our BAs started working on requirements for new features, I volunteered to be the customer / support liaison to help them figure out which customers were stakeholders and what current processes looked like.

– I offered to review requirements documents from a support perspective – which helped me learn heaps about how to write requirements. I was extra lucky because there were four BAs in the team with different styles, so I had different styles and perspectives  to learn from.

TL;DR – I learned what people wanted from the BA role, tried to learn those skills and made it visible that I was trying.


I’d done a decent amount of groundwork, and I was lucky that a BA role came up internally. I applied so fast for the role, I probably broke the sound barrier. But another essential part of the process was buy-in from my manager and the heads of the 2 different areas, because internal moves mean figuring out back-filling roles. I was so lucky to have enormous support from everyone involved, including being able to start the BA role part time for the first couple of months.

Another thing to consider was salary. A junior BA role didn’t pay much more than a senior support role, and perhaps even less once you included performance bonuses. This one took a little negotiation and long term thinking, but it was sooo worth it for me. I do wonder what the situation would have been like if I’d been a developer moving sideways though – probably a lot harder.

Finally, I was super, super lucky to work for a company that believed in retaining and promoting staff internally. This is probably the single most important factor that allowed me to make the role change. So if this is a change you are intending to make, this is probably the first thing you want to think about when you are starting out!

Zain at Xmas

Yay, you’re a Business Analyst! So now what?


əkˈsɛləreɪt/ verb

  1. Begin to move more quickly.

“the car accelerated towards her”

  1. Increase in rate, amount, or extent.

“inflation started to accelerate”

Synonyms: speed up, hurry up, get faster, move faster, go faster, drive faster, get a move on, put on a spurt, open it up, gain momentum, increase speed, pick up speed, gather speed;


You’ve made it this far! Your business card says “Business Analyst” (or a variation thereof). You’ve managed to use your years of experience doing what you do to get a job that allows you to be nosy, pull apart processes and systems to see how they work, and how they can be improved.

So what are you going to do next? How are you going to accelerate your learning and growth? What can you do to supercharge your Business Analysis Career?

You may not find answers here, but you’ll find some stories about a somewhat rocky, sometimes ridiculous, always eventful journey!

Some things to consider:

– What is a BA anyway

– What should I know before I start

– How can I learn more

– What is the one thing I can do to be a successful BA