I recently had a conversation with a product team interested in understanding my approach to product and feature development. During the course of the conversation, we stayed high-level, however, if you want more details <coded language for nerds> I’ve included a list of sub-processes at the end of this post.
The starting question —
“Walk us through your approach from taking an idea (a product feature) to handing it off to Devs and seeing the feature come to life.”
<Disclaimer start> Answering this question holistically is difficult due to the number of branches on the decision tree. There are an enormous number of tools, infographics, and certifications out there for this exact reason. It is a mix of product science and personal team style. What I'm explaining below is my most common approach. </Disclaimer end>
Assumed pre-conditions
1. There is already something like a development process established.
2. There is an alpha version of our product out there being used by real humans. I am assuming this because starting from 0 is different and much harder than building off existing products and processes.
Answer
A. The starting idea comes from almost anywhere - could be developers, market/user research, stakeholders, designer, someone had a dream, etc.
B. The idea goes through a simple vetting process normally comprised of a couple of conversations with architects, stakeholders, and so on before moving onto user/market research if needed. I might create wireframes, feature specifications documents, user flow diagrams, etc. This step varies widely from a couple of hours to weeks of work - it all depends on the idea. Every product manager I have worked with approaches this differently, personally I stress the need to solve user problems over feature delivery.
C. At this point, it's time for detailed prototypes and designs to test and get feedback on. If there is a designer, I'll work with that person closely during this whole process. I'll have a few refinement meetings with the technical crew to make sure we know how to build it. Often times, if speed is of the essence, the critical path allows technical infrastructure (new repos, pipelines, function apps, etc) to start being built before frontend development starts.
D. Next, detailed tickets need to be cut inside whatever ticket tracking system you use. Tickets are the meat and potatoes of feature development and go hand and hand with reviewed designs. I've used more systems for ticket tracking then I care to count - JIRA, Notion, DevOps, Clubhouse, Trello, Monday, Asana, VersionOne, on and on. They all have their pros and cons. Once you've got tickets on the board, it's time to use your existing development process of choice - Scrum, KanBan, XP. I'm a big fan of KanBan if your team is disciplined enough to work well together without a ridged process. For new teams, a Scrum process normally does the trick.
During actual development, new design needs and unforeseen issues ALWAYS come up, so I'll adjust tickets, make new designs, work with architects, and so on. The point is to make sure the team has what they need and we keep "solving the user's problems" at the heart of the work being done. Steps C. and D. are often where design bottlenecks appear. This often has to do with how design, product, and dev have chosen to collaborate - What user flows were missed? Was refinement done poorly? Did the designer unknowingly change the information architecture of the system? Did development not think through the designs deeply enough before trying to build them? These questions go on for a mile, but at the end of the day, the designer must understand the system and users they are designing for, and development must think through and be critical of designs before they hit the development process.
E. While the above has been going on, I've been doing release planning to see when we can deploy this new work to real human users. I'm also getting the next set of work ready for development using this process at the same time. I'll be talking to marketing and customer support to make sure they are coordinated with what's coming. And lastly, I'm working with a data analytics person or tools (segment, amplitude, etc.) to make sure we are properly tracking our user actions for the upcoming features. It's a continuous cycle with dozens of slight variations in execution.
F. Finally, tickets pass QA and UAT - we have a valuable and deployable piece of work ready for users. It's time to follow our deployment process and studying how users are interacting with our new ideas.
Of course, there are many other ways we could arrange and approach this process; not counting the whole other process of monitoring and reacting to users out there in the real wild internet-world. Scary.
If you want more to study -
Buried within this explanation are about a dozen other processes that are each deserving of their own post. I’ll end this article with a list of those processes I referenced above.
Idea refinement process
Market Research process
Design Thinking Process
Product Prioritization process
Technical development process (Scrum, Kanban, and so on)
Stakeholder management process
Release planning and the “Critical Path” process
Deployment process
User research and analytics tracking process