It’s execution time!
You know what is the feature you want to be built. You know why it needs to be built. And you decided that now is the time to get it into the works. Fantastic!
Now what?
Now it’s the delivery time. I call it ‘The product delivery process’. This process involves a group of people and roles and each plays a major role in the delivery of the feature. Depending on your organization size and the size of the feature itself this group may consist of developers, QA, data analysts, UX/UI designers and/or product marketing. At the bare minimum, you will have one or two developers and that’s it (in very small companies\startups) and the bigger the company is – the more roles from the list above will take part in this process.
Who needs to orchestrate it all?
For most cases – this is on you!
From time to time, though, and especially in cases where the feature is big and involves several teams, you may have a project manager accompanying you or even taking over the orchestration.
No matter who is officially orchestrating the delivery process – my advice to you is that you should always aim to see yourself as the lead and owner of the process. The reasoning: if things start falling apart in terms of delivery, and unless there is a very clear part of the chain that is failing to deliver, then there is a good chance you’ll be held accountable. There is some justification to it after all – it’s your feature everyone is working to deliver so you are the default to blame (“the spec wasn’t clear”, “the spec wasn’t delivered in time/too long ago”, “we asked on Slack but no one answered in a timely manner”, etc…)
Don’t worry, though. I will help you manage the delivery process like a pro.
Now, since there is a lot of wisdom to share – I will split my advice into three separate posts. In this post we’ll discuss the core principles which should guide you in your interaction with your colleagues.
In the post afterwards we will review closely the ‘chain of delivery’ – e.g. – all the stages the feature which is being built needs to go through, and who owns each of the stages.
In the last post we’ll delve deeper into the agile methodology you can choose from, and what it means to you when orchestrating the process.
Ok – so let’s get the ball rolling.
The Core Principles of the Product Delivery Process
I am gonna outline several principles below. Fully understanding and following these principles will minimize the risks involved with features and/or product delivery by promoting trust and effectiveness across the delivery chain. Whenever you run into a situation where you are unsure what to do next – consult these principles and for most of the time – they will provide proper guidance.
P1 – You are all on the same team
Yes, the delivery chain consists of several roles & teams, but you need to understand something very basic – like a relay race in real life – if one of the stages on the delivery chain doesn’t deliver – the whole chain doesn’t deliver. Hence, there is no ‘us’ and ‘them’.
Never adopt the state of mind of ‘I did my part, it’s the R&D who screwed up’. The R&D may have indeed screwed up. It’s still your problem at the end of the day – because the feature won’t get delivered (on time). It’s not the time to be righteous because it will get you nowhere. It’s the time to offer your help and see if there is anything you can do to assist. And be willing to get out of the formal boundaries of your role.
For example – in one of my previous workplace the QA team started to get really behind in terms of approving features. The features built by the R&D were piling up and the QA were struggling to get everything tested in time. We set up a meeting – product, R&D and the QA and discussed what we can do to help. The R&D ended up voluntarily taking some of the QA tasks on themselves. From my side – I made some changes in the prioritization of the tasks, so more trivial tasks will get into the work now, and keeping the heavy features for later on. I also approved ‘cutting some corners’ for the execution of several tests (shhh… don’t tell anyone…).
Another example – I once saw that the R&D team leader is struggling with his calendar. He had back-2-back meetings all day long and his team really had a hard time getting his attention. I offered my help and we reviewed his calendar together. We managed to free about 30% of his time by smart delegation and removing him from unnecessary meetings.
I did it because I understood that their problem is my problem at the end of the day. And you know what you’ll gain by doing this?
TRUST
The trust of your colleagues is worth more than gold. They can trust you to be there when they need it. They will do the same for you.
Lack of trust kills delivery. Lack of trust can do a lot of other bad stuff. I’ve seen more than once people losing their job due to lack of trust from their teammates. Hence, be there when they need you. And a side bonus of that – it will make you feel good with yourself, regardless of everything else. Worth it.
P2 – Single Point of Contact
You are the owner of the 3 ‘w’-s – the ‘why’, ‘what’ and ‘when’. The R&D owns the ‘how’ (with two exceptions, will get to it shortly).
No one should reach out to the developers directly and assign them with tasks. If you allow that – you’ll break everything and things will soon get out of control.
The sales want something urgent for a big customer? They should talk to you. The business guys just want a ‘very tiny change’ of a parameter value from X to Y? They must talk to you. The R&D team nearby wants to enable an API and ‘it should take only 2 mins’? They need to talk to you.
Small things quickly turn out to be big things from my experience. Even if the coding itself takes indeed 2 minutes – it still needs to get tested and get into production. Too often I saw tiny changes causing big disasters. Everything needs to go through you, for understanding why it’s needed and when it should be implemented.
In ALL the workplaces I’ve been to – this wasn’t the case when I came on board. It resulted in chaos and lack of focus. It was therefore also one of the first things I changed right after starting my new role.
It may annoy some people. Some even may try to escalate this to your boss and complain. Stand firm. Don’t give up or you will quickly lose control over your roadmap.
The R&D team who is assigned to you will appreciate it as well. The worst thing for developers is context switches. Protect them and keep the noise out of the door. They will later thank you for that.
And if they say – ‘well, I don’t feel comfortable turning down a business guy who is much superior than me’ then tell them:
‘Don’t turn down anyone. Tell everyone – ‘sure, no problem. Just run it by product so they can put it into the queue’. Take it on yourself to be the bad guy.
Again – this will result in TRUST and appreciation by your colleagues. Eventually, from my experience, the organization will soon adjust – and will stop trying to sneak features ahead of the queue and come to you directly.
As I noted above – there are two exceptions to that:
- Tech debt tasks – where the R&D (and sometimes the QA) will define the ‘why’ and the ‘what’. You will only have control over the ‘when’. I will devote a post to tech debt tasks in the future.
- Production issues. You still need to be aware of those, because it may affect the delivery of other features, but it can’t ‘sit down’ and wait for you to prioritize that. It takes priority over everything else. However, do notice that sometimes the sales/business or others may try to sneak features as production issues. In that case – stop that in time and change it to a ‘feature requests’.
P3 – Single Source of Truth
The product delivery process is a pipeline with several stages. Most of the stages produce some sort of documentation as their primary goal, or as a side effect.
Here is the list, out of my head (and I may have missed one or two):
- The productization phase results in a product specification
- The R&D stage includes, as a side-effect, adding implementation tasks to the tasks management system.
- The QA guys are producing a test plan.
- The UI/UX people create the product design
- The product marketing team creates the marketing plan
The owner of each stage must make sure their produced documentation is the single source of truth for that stage. For example – the product specification is the single source of truth for the ‘why’ and the ‘what’. The Jira tasks (or whatever tasks system the R&D is using) are the single source of truth for the ‘how’. The Zeplin files (again, just an example of a common tool) are the single source of truth for the look & feel of the feature and so forth.
The data & information associated with a single feature must not be scattered across multiple places, products and platforms. You agreed with someone on Slack on a change for the feature? You MUST update the spec. The R&D are discussing over the email several possible implementations and make a decision? This decision must be reflected in their Jira tasks. The developers sat with the product designer and convinced the designer to change the font? This decision needs to propagate back to the Zeplin files. There must be a single document that encompasses the test plan and the QA team can tell you where it is.
Slack & emails decisions and communications don’t count unless the owner copied the decision and adjusted the single source of truth with it.
For instance – personally, I manage the product specifications mainly with Google Docs. I use it for non-trivial features. For the trivial ones – which don’t require a full blown spec and consume at most one paragraph – I simply add it as a Jira task directly and communicate this to the team. But I never have a feature which is documented on both platforms. Every time I agree to change something in the requirements – I go to the single source of truth – and update it there.
This may take time for some people to get used to – but be disciplined about it because it will eliminate confusion and eliminate cases where people are working on the wrong thing because they saw something on Slack.
Everyone will get it eventually that only what’s written on the ‘single source of truth’ is what counts.
P4 – Agile Approach
A lot is written about ‘agile methodology’, ‘agile development’ and so forth. I’m not going to repeat it.
To summarize what agile means to me I’d say that it’s all about quick iterations and incremental value to your customers and users, rather than working on ‘big chunks’ and delivering once in a while.
You should strive to be agile with your delivery process due to tons of benefits that come with it:
- Getting feedback sooner rather than later and being able to adjust
- Effective experimentation
- Validating/invalidating assumptions early on
- Sense of accomplishment (don’t underestimate this!)
- From the customers POV – a great company which always innovates and delivers fast
And there are more…
There are several agile methodologies available to choose from, with Scrum and Kanban being the two major ones. I will detail which approach is my favorite and why on the third post in this series.
For now, however, there is one thing I’d like you to keep always in mind:
The methodology needs to serve you and not the opposite way around.
Don’t be a ‘scrum fanatic’ that does everything the Scrum playbook says just because ‘this is how you do Scrum’. This doesn’t end well, I assure you.
Instead – work with your extended team – mainly the R&D and the QA to come up with a method that sounds good to all of you and give it a try. Adjust as you go. You may end up doing a mixture of several methodologies but as long as features are being delivered in high quality and in a timely manner – that’s all that counts!
So those are the core principles I follow when executing the product delivery process. It helps me a lot on my day-2-day job. I’m certain it will help you as well.
That concludes the first part of this series. If you find it useful – feel free to ‘like’ it. If you think it can be beneficial to your friends or colleagues – feel free to share it with them.
Until next time.
