The Product Delivery Process – Part 2
This is the second post in the series about the ‘product delivery process’ – the process which covers how a feature goes from ideation to production.
In the first post we discussed the core principles of the product delivery process, which were (by their titles):
- You are all on the same team
- Single point of contact
- Single source of truth
- Agile approach
Feel free to refresh your memory as for what each means by visiting the post.
Today we’ll discuss the general stages of the delivery chain, who is the owner of each and what does it mean to you.
Let’s start with the main flow which describes the common feature lifecycle before it gets to production:
Let’s go briefly over the stages in this simplified diagram:
The Ask
This is the stage where you, the product guy, become aware that this feature is needed. The request can come in the form of a feature request through one of the official channels in your company. For example – one of the customer support representatives receives the request and submit it to whatever system you use for storing feature requests. Other options could be that the sales guys come knocking on your door asking for that, or maybe it’s you who records this request after conducting a customer interview. No matter the origin, you did your research, you understand the ‘why’ and you decide now is the time to promote it.
The Spec
This is the stage where you sit down and work on the product specification. The product specification (or ‘spec’ in short) will become the single source of truth for the ‘why’ and the ‘what’ for this feature. I will devote a dedicated post as for what this document must contain, and how it should be structured so don’t worry about it now.
I will note, however, that this is the point of time where the UX/UI designer needs to be involved, in case the feature does contain a user interface. The designer will work on their contribution to the ‘what’ by iterating with you on the user interface and the user flows. Their resulting work needs to be embedded in the spec (will explain how in the promised post above :-)).
The Spec Review
Once you complete the work on the spec and if the feature is non-trivial – you must conduct a spec review meeting. All the internal stakeholders need to be summoned to this meeting, including the feature requester (unless they are a customer or an external user), everyone who is going to work on the feature (developers, QA, product designers, product analysts, product marketing) and anyone else who showed interest in this feature in the past.
This meeting is super important as it’s the place to align everyone on the why and the what. This is also their opportunity to challenge your decisions and/or provide useful feedback – so you need to be prepared.
Yes, I will devote a future post as for how to manage this meeting like a pro, but for now – make sure it happens, make sure you summon anyone who is relevant, be prepared and be open to feedback.
Once the spec review ends – apply all comments (this may require some iterations) and finalize the document.
After the spec review the process is split to a side track and the main track. The side track is all about the QA and their work on the test plan while the main track is about moving onwards to the implementation stage.
Those two tracks can and should be promoted in parallel as they are independent.
The Test Plan
With the exception of automations, the test plan needs to be based on the spec, and the spec alone. Several times in the past I’ve noticed that the QA engineers are delaying their work on their test plan. When asked why, I usually get the answer that they are waiting to hear from the engineering as for how they are going to implement the feature. To me, this doesn’t make much sense. As I see it, the test plan needs to verify that the ‘what’ was implemented as required. The test plan shouldn’t be testing the ‘how’. Hence, the implementation details shouldn’t affect the test plan at all (again, with the exception of QA automation scripts, which need to be integrated based on the actual implementation).
Anyway – once the test plan is ready – it should be reviewed by you and the engineering team. From what I’ve observed – in many occasions this is the stage when the engineers truly understand what is expected of them in terms of delivery, and you should expect some unique feedback to arise that you usually won’t hear during the spec review sessions.
So, aside from the fact that we will have an agreed upon test plan – you will further increase the alignment within the team and that’s great!
The R&D Design
Meanwhile, on the main track – the developers are moving on to work on their design as for how they are going to implement the feature. Again, depending on the feature’s size this stage may take 5 minutes, or may take several sessions and even split to high level design and detailed design. Again, this is another (informal) opportunity to raise questions about the spec, but this is usually also the first step where you’ll be requested to make some meaningful ‘sacrifices’.
The developers may complain, for example, that a requirement to be ‘real time’ will be very expensive in terms of resources or drastically complicates the design, while if you allow relaxing the requirement to be ‘near real time’ – then it will be much cheaper and easier to implement.
You will need to make a decision, and each decision will have its price tag.
Very often, though, you won’t be involved in the design process – and that’s perfectly fine. In fact – I prefer this reality for reasons I’ll detail in future posts. But in short – the more you’ll be exposed to the details of the ‘how’, the more it will subconsciously affect you to write your future specs in a way which caters to the current implementation, rather than to your clients needs.
The output of this stage may or may not contain a design document. However, the important thing to make sure of is that the implementation tasks are submitted in an orderly manner to the tasks management tool (Jira or the similars). These tasks need to be wrapped with a major EPIC task which is mapped to the spec (more of that on the next post). But anyhow – those tasks represent the single source of truth of the ‘how’.
The implementation stage
Although this is one of the main stages in terms of overall effort, from the product’s perspective – it’s quite boring. This is your time to promote some other work which is not related to this feature. Alternatively, it may be a good time to reach out to your product marketing point of contact and start working on the press release (in case you have this function in your company and in case the feature is customer facing, of course).
I guess what I’m trying to say is that at least on your front – this is ‘quiet time’ you can use for whatever makes sense.
The Review Stage
This stage often doesn’t exist in many places I’ve been to. I strongly suggest adding it. It’s short, but highly beneficial.
The essence here that you and the UX/UI designer need to review the final implementation and make sure that’s what you meant – before it gets to QA.
If the feature has a user interface, then this is the point in time where the designer needs to verify that the implementation adheres the UX/UI spec. If it doesn’t have a user interface then you’ll probably have nothing to see with your own eyes, but you can and you should ask some questions.
You won’t believe what you’ll discover just by going with the developer over the spec and pause on the important sections and ask the developer whether they made sure it’s properly working.
The less disciplined your organization is in terms of developers testing, the more chances for you to discover that some basic developer testing hasn’t been performed for some of the key aspects of the feature. And now that the developer is testing the flow it actually doesn’t work.
There is no point bothering the QA if the main use cases have never been tested by the developers on their local environment. Context switches hurt QA the same way it hurts developers. You need to protect their time as well. If you won’t do it – the feature will travel back and forth between the QA and the R&D, and trust between the two will be compromised.
Thus, again, adopting core principle #1 (‘you are all on the same team’ state of mind) will result in trust & efficiency and eventually – increased discipline that will add even more to the overall delivery efficiency.
The QA Stage
From your perspective – it’s a bit similar to the implementation stage. Free time for you!
One advice though – usually, if the QA stage completes successfully then in many organizations the feature will proceed straight to production. My advice is that you’ll ask to be the one authorizing the move to production. It will allow you to control the timing of when the feature is released. This is crucial when the feature is big and has a release plan attached. In that case you’ll probably need to agree on the release time with the product marketing department.
However, this is useful also for features which are simply risky (either because the implementation ‘touched’ sensitive parts of the code or because it changes some of the main flows the users are working with). You don’t want to release such features on the weekend OR when you don’t think you or the developers can respond in a timely manner if something goes wrong.
You have the bigger picture, so you should be the one clicking on the button.
That’s it when it comes to the main flow.
They are also supporting flows. Mainly the flow when a bug or a production issue are discovered. Those are working a bit differently, but I won’t delve on them now.
Yes, I didn’t mention too many times the product data analysts and the product marketing guys. There is a different reason for the absence of each.
For product data analysts – they are supporting you and in many cases may even report to you. They will support you when working on the spec and after the feature is released. They will dig data for you and help you make data driven decisions. I will devote at least one post on how you interact and manage them. However, for the sake of the product delivery process – they don’t make a separate stage, but rather should be seen as part of the ‘product’ function and ownership.
As for the product marketing function – they do deserve a stage of their own, but on the day-2-day they won’t be involved with many of the features. Also, depending on the size of your company – this function may not even exist. Here again, I’ll make a promise to dedicate a post about the best practices of interacting with the product marketing guys.
That pretty much concludes the second post on the series. On the next (and last) post on this series – we’ll discuss what agile approach actually means on the day-2-day, and how to choose between Kanban or Scrum.
As always – if you found this post beneficial I invite you to ‘like’ it and also share it with anyone else who you think could benefit from it.
Thanks and until next time!