15 days until #mtpcon London, the world’s best product conference
Book now
The 10 things I have learnt about Agile Product Delivery "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 12 March 2014 True Agile, Delivery, Execution, Lean, Minimum Viable Product, Product Delivery, Scrum, Strategy, Mind the Product Mind the Product Ltd 1143 Product Management 4.572
· 5 minute read

The 10 things I have learnt about Agile Product Delivery

AppleI have a confession. I share it in the belief I am in the company of my brethren; I am an accidental product manager. Two years ago, I did not know a user story from a bedtime one. A notification from an alert. And a gherkin was still just a tasty pickle.

But 24 months is a long time in agile product management and I have had to learn. Fast. One of the insights I have gained is that sharing experiences with the motive of betterment is one of the core tenets of agile philosophy. So, I humbly submit the 10 things I have learnt about managing agile product delivery, in the hope others will find value and enrich with their experiences.

1. The hook and the anchor

In any agile delivery there will be good times and there will be bad times. And when the bad times come, you will need something to keep the momentum going for your stakeholders and yourself. This requires preparation, data and a compelling reason for doing what you are doing. For us, this involved an initial business discovery project, which included meeting and surveying our clients. This enabled us to do two things – define a succinct value proposition for the problem we were trying to solve and survey data and client testimonials we could turn to when times got hard.

The other (not to be overlooked) benefit was that it enabled us to take reduce resistance from nay-sayers.

2. Love the job and get s**t done.

After university, I fell into a role in Financial Services and spent most of my career working at the intersection of strategy, technology and operations.  My move into product management whilst accidental, was then, perhaps inevitable – all good product managers operate at this confluence, as this is where ‘s**t gets done’. Do not misunderstand me – writing personas, defining true north value propositions, wireframing features and coming up with joyous user experiences are all critical facets of the product management function, but the ability to mobilise resources to deliver the right product at the right time is what sets one product manager apart from another.

I once commented to a friend that for an MBA grad like me, this was the ideal job. And in the right environment, it is. So, love it. There are far worse things to do and few better.

3. Be with your teams…

I have hired (and fired) project managers, business analysts and product owners and the one thing I have learnt is if you are the ‘product person’, you cannot hire your way out of day-to-day interaction with the people building product.  Be it start-up or at scale, when you try to convey vision from afar, you lose something fundamental. If you are not willing to make the trade-off, don’t try it.

4. Full-stack, fully dedicated and collocated teams…or bust.

For over a year I managed the interaction between an off-shore ‘front-end’ development team and an on-shore ’back-end’ team. It was a train-wreck. And the train was my product.

Putting aside cultural and logistical issues, if your objective is a unified focus on a single outcome – building great products, then managing teams with different objectives and agendas is not an option.

It is my belief that a product manager must do everything within his or her power to make team focus and collaboration towards a single vision a top priority. And a single team with a single focus is the most important thing to help make that happen.

5. Only create stories a user can understand.

One of the indicators of product leadership is the type of work that goes ‘on the board’ (NB: Always have physical boards for your teams, even if you also use a digital one).

Stories (or whatever medium you use to communicate requirements) that only a technologist can understand are almost always the result of ineffectual product leadership and will be to the detriment of your product, and therefore users.

Take responsibility for requirement creation and only create ones that an end-user could understand. The team may create more technology-orientated sub-tasks and that’s fine, but the only thing that should move along a board or be measured should be understood and valued by users (without the need for an interpreter).

6. Small stories.

A related insight is the value of small stories.

We have a rule that any story bigger than a specific size (in whatever currency you measure such things – points, days etc.) must be broken into smaller stories.

This serves two purposes – firstly, it helps velocity, and secondly, it helps to force product people to think about MVP in terms of feature sets.

7. Architect-in-time.

In my experience, architectural design and implementation should emerge in the context of delivering requirements. The promise that early architecting will address future problems (e.g. performance, maintainability etc.) is seldom delivered upon in a way that is more efficient than emergent design.

However, the risk of over-engineered solutions that address at best hypothetical, and at worst imagined requirements, severely impacting your budget, timeline is a clear and present danger. Guard against it with your life – technologists are responsible to the business for a reason, do not willfully give up this accountability.

8. Evolution, not iteration.

In line with ‘lean’/MVP thinking, build atomic features of value to your users and release these as quickly as possible with a mechanism to capture feedback. Use the feedback to evolve the feature. Release the improved version, and repeat.

Feedback from your user base is the lifeblood of any product management function. Do whatever you can to get it and get it early.

9. Manage a process improvement board.

Velocity is your friend and the people building the product generally know how to improve velocity. Do what you can to empower the team to deliver features quickly. If you think this is the responsibility of the ‘scrum-master’ or ‘programme-manager’, you need to rethink your objectives.

10. Carry your stakeholders through the journey

In many firms, product management is a relatively new function and in many more, agile is. Help your stakeholders – provide them with good updates, explain key jargon and avoid ‘fluff’.

Agile done well is an incredibly powerful way to deliver superior products and create competitive advantage for your firm, but there are risks; Agile provides speed and done badly or misunderstood by executives, will lead to failure quicker than you can say ‘waterfall’.

So there you have it – the 10 things I have learnt about agile product delivery.  By no means an exhaustive list, or faultless – but in the agile spirit, shared for growth and further improvement.

There are lots of things I have still not worked out – for example, how to get the best out of project managers, how to better align technology and business interests or how to best use JIRA(!), but hey, it’s a learning process!

Comments 7

Hi Brij..
It is always as nice and informative to read your articles, as it was to work with you. I’d worked with you on BCA’s project from Aptara’s team and has always appreciated your way of working as Product Owner.

I work in a globally dispersed team, and we’ve had trouble adopting true Agile practices for a long time now. Your point (4) above, and other tips on implementing Agile I’ve read, make it sound like we’re not alone here. Is doing true Agile with a global team really even practical?

Hi Jeff,

Thanks for the feedback.

Putting aside panacea style frameworks such as SAFe, my view is that agile can scale globally if you treat it as a fractal. However, if you attempt to crack the atom – you will end up with a mess of nuclear proportions!

Somethings work, and somethings don’t and you have to be willing to accept that as soon as you create distance you lose something (anyone who has tried to hold a stand-up over Skype can appreciate this).

I would take baby steps to scale up and see what works for your teams.

Love the article, and share the same pains as Jeff though. My solution? Get everyone on IM, phone, etc. and stress for them to call NOT just email or update a status in some system when you are passing the ball back to the PMs or BAs. I’m as busy a Product Manager as the next guy, handling hundreds of users (Front Office finance), but I try to stress my door / phone is always open. It’s challenging since I’ve had contractors outside of my office not only working for us as a client, but another client! This is generally unheard in my line of business where we are typically / contractually the only client, but you do the best you can with the hands you’re dealt right? 🙂 We found a way but it was certainly a hurdle! I commend you for sharing your stories here!

Join the community

Sign up for free to share your thoughts

About the author

#mtpcon LONDON | 20 OCT 2023

Join world-class product experts for a jam-packed day of inspiring talks and interactive sessions

Book now