Hey, Scott. Engineering, data science, architecture… they’re critical to the success of discovery — not only do they have great ideas, but they can guide discussions around feasibility. For example, the team gets excited about a portion of the prototype that will actually cost the company another $2M and 6 months of R&D.

As someone who wrote code for 7 years, I know the pain of being dragged into requirements meetings or brainstorms, or the dreaded meeting about the meeting. It also doesn’t help that the process has the word design in it. Tech folks are a busy, skeptical, and often taken advantage of group. You have to demonstrate to them that by spending 1–2 days in a highly structured and actionable discovery process will save them countless headaches, Q&A, and rebuilds.

It won’t happen overnight. Start by inviting 1 engineer who likes the idea of being involved in discussions about why and what he’ll eventually build. Assuming he loves the process as much as most other engineers who I’ve involved in my sprints, make him your sprint evangelist within tech.

If things go as I know they can, in a year or so from now, you should have more than a few engineers pushing back on working on things in the backlog that have not been through a design sprint.

I’m also happy to talk with your team and share stories and tips. Give me a shout — jay@newhaircut.com