Your developers can steer you right.
This week: We dig into how trusting development teams can help build stronger products.
If there’s one thing I’ve learned over the years, it’s that breaking down high-level work into smaller, actionable tasks is never as simple as it seems.
I used to believe that the more polished a plan was before sharing it with the dev team, the better. But then came that project - one where the fine print derailed the timeline because we hadn’t tapped into the dev team’s expertise early on. Since then, I’ve learned that early collaboration often prevents those costly mistakes.
This idea was reinforced when I read
and his post on 7 Signs of Scope Bloat I No Longer Ignore. It hit home because, like many product people, I’ve felt the pressure to have everything buttoned up before engaging with the development team.But here’s what I’ve come to understand: getting developers involved early and often not only helps fill in the gaps you might have missed, but their insights can steer the project in ways you didn’t expect - often for the better.
The power of collaboration.
In recent years, I’ve come to value the input of development teams more and more. Their insights often reveal potential roadblocks or complexities I wouldn’t have seen otherwise.
Especially now, with many companies moving away from the traditional BRD (Business Requirements Document) model and no longer having dedicated business analysts, it’s become more crucial than ever to collaborate closely with developers throughout the process.
I’ve found that when I loop them in early, it’s not about them executing on a polished, pre-packaged spec - it’s about building something together. The dev team often knows the technical nuances and limitations that can push an idea forward or require a pivot. When we work together from the beginning, it reduces misalignment and unnecessary rework.
Making the Most of Dev Team Feedback
Through trial and error, I’ve developed a few tactics that make the most of the feedback loop with dev teams:
Unveil in stages, but keep it collaborative.
In the past, I’ve fallen into the trap of waiting too long to share work with the dev team, thinking that unveiling everything at once would lead to a smoother process. But, as I’ve learned, waiting until the plan is perfect can cause more harm than good. Even if the plan isn’t fully baked, sharing rough drafts invites the team to weigh in on technical feasibility early on. It also allows them to help fill in details you may have missed and highlight where decisions must be made.Create room for open dialogue.
One of my favorite moments in product development is when a developer brings up a question or idea that hasn’t crossed my mind. These moments don’t happen if communication is one-sided. I’ve started approaching reviews and check-ins as status updates and open discussions. Letting the team challenge assumptions and propose alternative solutions has led to some of the most efficient and creative outcomes.Define success together.
I often go into a project thinking I had the right success metrics mapped out. But after talking with the dev team, they’d highlight additional factors like performance impacts or scalability that should also be considered when defining success. Working together to align on what “good” looks like ensures everyone is rowing in the same direction.
Why does this matter in product development?
There's been a noticeable shift in the last couple of organizations I’ve worked with. We increasingly see the responsibilities once held by business analysts being absorbed by product owners. Business analysts were typically responsible for getting into the field-level details - those minor, granular work aspects vital to shaping the final product. However, this role is being phased out or significantly reduced in many organizations.
On the surface, this might seem like a disadvantage. With fewer people dedicated to those finer points, it’s easy to wonder whether some essential details could slip through the cracks.
But here’s the flip side: this shift allows software engineers and developers to step in and contribute creatively. Without rigid requirements or pre-defined solutions from a business analyst, developers can use their technical expertise to help shape how we achieve product objectives.
I’ve found that this new dynamic can lead to much more intelligent, more innovative solutions. Rather than being limited by overly detailed specs, dev teams now have the space to consider how best to achieve the product goals, often coming up with ideas that hadn’t crossed my mind during the initial planning phase.
It’s a shift that requires greater collaboration and trust between product and development teams, but when it works, it can lead to outcomes that are both technically sound and closely aligned with the product vision.
At its best, this collaborative approach delivers great products and fosters stronger relationships between teams, as everyone feels a sense of ownership and contribution toward the final outcome.
Final Thoughts
Involving your dev team early and collaborating with them throughout the process ensures that the work is aligned with business goals and built in the most effective way possible. You’ll save time, reduce unnecessary rework, and build a better product for everyone—especially the user.
Have you seen this play out in your experience?
How do you involve developers in your process to ensure the work hits the mark?
Hit me up in the comment section below and let me know your take.
Great post, and thank you for the mention!
Hi Mike, It is not all about involving the tech team in the discussion earlier, the problem remains always in the quality time the team invests in assessing the roadblocks. Moreover, the expertise and skills required in the "sharing thoughts" stage are somehow distinct from the day-to-day ops. An open-minded and solution-driven mindset is key to making that early engagement successful. Otherwise, you will be only dived by limitations.