post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Artificial Intelligence (AI) & Machine Learning (ML)

Microsoft lays off 3% of workforce while renogiating partnership with OpenAI

Podcast

How to build the right product culture during transformation – Joca Torres (Product Consultant)

B2B product management

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Context, intent, change, purpose, constraints – a model for communicating requirements

5 difficult conversations and how to have them

DoorDash eats Deliveroo while OpenAI makes its biggest buy: This week’s news roundup

Why great product managers think like therapists

Tools and techniques to scale product teams – Charlotte King (Lead Product Manager, eBay)

Brijesh Malkan is a Founding Partner of EGO Ventures – a firm that aims to disrupt and democratise financial services. 

Brijesh is currently wrapping up a long-term consulting engagement with a leading investment research firm, where he has been working in the role of Product Director. Brijesh can be contacted via email on brijesh.malkan@ego-im.com

Brijesh Malkan

<img loading="lazy" decoding="async" class="alignright size-medium wp-image-4665" alt="Apple" src="https://www.mindtheproduct.com/wp-content/uploads/2014/02/apple-300x198.jpg" width="300" height="198" srcset="https://www.mindtheproduct.com/wp-content/uploads/2014/02/apple-300x198.jpg 300w, https://www.mindtheproduct.com/wp-content/uploads/2014/02/apple-1024x677.jpg 1024w, https://www.mindtheproduct.com/wp-content/uploads/2014/02/apple.jpg 1280w" sizes="auto, (max-width: 300px) 100vw, 300px" />I 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 &#8211; 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 &#8211; 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 <abbr title="Minimum Viable Product">MVP</abbr> 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 <a title="Minimum Viable Product - The Minimally Viable Feature Approach" href="https://www.mindtheproduct.com/the-minimally-viable-feature-approach/">‘lean’/MVP thinking</a>, 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 &#8211; 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&#8217;s a learning process!

core/freeform

Agile Product Development

Better value sooner, safer, and happier by Jonathan Smart

Building Successful Product Development Teams, by Simon Colmer

How to be a Successful Product Owner, by Ninon Laforce

Out of the Fog by Holly Donohue

How Design Thinking, Lean, and Agile Work Together by Jonny Schneider

Lean, Agile, & Design Thinking by Jeff Gothelf

Tales of two Continuous Loops by Tim Beattie

Agile With a Capital A Might not be Best by Morag McLaren

How to Apply Lateral Leadership in Agile Environments by Tim Herbig

Owning Agile by Jeff Patton

The 10 things I have learnt about Agile Product Delivery

ProductTank Valencia

ProductTank Auckland

ProductTank Helsinki

ProductTank Barcelona

ProductTank Lomé

ProductTank Wellington

ProductTank San Diego

ProductTank Canberra

ProductTank Perth

ProductTank Hong Kong

ProductTank Bangkok

ProductTank Doha

ProductTank Tel Aviv-Yafo

ProductTank Baku

ProductTank Reston

ProductTank Raleigh

ProductTank Charlotte

ProductTank Washington

ProductTank Richmond

ProductTank Cluj-Napoca

ProductTank Zagreb

ProductTank Amsterdam

ProductTank Edinburgh

ProductTank Paris

ProductTank Hamburg

ProductTank München

ProductTank Buffalo

ProductTank Manchester

ProductTank Bristol

ProductTank Oxford

ProductTank Madrid

ProductTank Des Moines

ProductTank Dallas

ProductTank Portland

ProductTank Curitiba

ProductTank Chicago

ProductTank Austin

ProductTank Philadelphia

ProductTank Montevideo

ProductTank São Paulo

ProductTank Los Angeles

ProductTank Gdansk

ProductTank Stuttgart

ProductTank Pittsburgh

ProductTank Bangalore

ProductTank Chennai

ProductTank Mumbai

ProductTank Fribourg

ProductTank Norwich

ProductTank Zürich

ProductTank Newcastle Upon Tyne

ProductTank Jacksonville

ProductTank Florianópolis

ProductTank Tallinn

ProductTank Buenos Aires

ProductTank Denver

ProductTank San Francisco

ProductTank Sheffield

ProductTank Tokyo

ProductTank Valletta

ProductTank Bologna

ProductTank Vancouver

ProductTank Milano

ProductTank Columbus

ProductTank Belfast

ProductTank Montréal

ProductTank Seattle

ProductTank Rotterdam

ProductTank Lausanne

Product Management Foundations BST

Product Management Foundations ET

ProductTank Reading

ProductTank Bielefeld

Communication & Alignment BST

Communication & Alignment ET

ProductTank Frankfurt

ProductTank Bonn

The 10 things I have learnt about Agile Product Delivery

Brijesh Malkan

Read more