๐Ÿค– AI can change how Product and Engineering collaborate.

Originally published on LinkedIn

๐Ÿค– ๐—”๐—œ ๐—ฐ๐—ฎ๐—ป ๐—ฐ๐—ต๐—ฎ๐—ป๐—ด๐—ฒ ๐—ต๐—ผ๐˜„ ๐—ฃ๐—ฟ๐—ผ๐—ฑ๐˜‚๐—ฐ๐˜ ๐—ฎ๐—ป๐—ฑ ๐—˜๐—ป๐—ด๐—ถ๐—ป๐—ฒ๐—ฒ๐—ฟ๐—ถ๐—ป๐—ด ๐—ฐ๐—ผ๐—น๐—น๐—ฎ๐—ฏ๐—ผ๐—ฟ๐—ฎ๐˜๐—ฒ. I donโ€™t know what we call this yet โ€” but itโ€™s working for me.

Iโ€™ve been experimenting with a new workflow โ€” one that doesnโ€™t start with a ticket, but with a business goal and technical reality together early. Using AI, rapid prototyping, and engineering intuition, I propose engineering solutions to business goals with working code they can see, not a ticket for an idea and requirements.

We all know the traditional flow: ๐Ÿ‘‰ ๐—ด๐—ผ๐—ฎ๐—น (๐—ฝ๐—ฟ๐—ผ๐—ฑ๐˜‚๐—ฐ๐˜) โ†’ ๐—ถ๐—ฑ๐—ฒ๐—ฎ (๐—ฝ๐—ฟ๐—ผ๐—ฑ๐˜‚๐—ฐ๐˜) โ†’ ๐˜๐—ถ๐—ฐ๐—ธ๐—ฒ๐˜ (๐—ฝ๐—ฟ๐—ผ๐—ฑ๐˜‚๐—ฐ๐˜) โ†’ ๐—ฟ๐—ฒ๐—ณ๐—ถ๐—ป๐—ฒ (๐—ฒ๐—ป๐—ด+๐—ฝ๐—ฟ๐—ผ๐—ฑ๐˜‚๐—ฐ๐˜) โ†’ ๐—ฝ๐—น๐—ฎ๐—ป (๐—ฒ๐—ป๐—ด) โ†’ ๐—ฏ๐˜‚๐—ถ๐—น๐—ฑ (๐—ฒ๐—ป๐—ด) โ†’ ๐—ถ๐˜๐—ฒ๐—ฟ๐—ฎ๐˜๐—ฒ ๐—ฐ๐—ผ๐—บ๐—ฝ๐—น๐—ฒ๐˜๐—ฒ๐—ฑ ๐˜ƒ๐—ฒ๐—ฟ๐˜€๐—ถ๐—ผ๐—ป (๐—ฒ๐—ป๐—ด+๐—ฝ๐—ฟ๐—ผ๐—ฑ๐˜‚๐—ฐ๐˜) โ†’ ๐—ฟ๐—ฒ๐—น๐—ฒ๐—ฎ๐˜€๐—ฒ

๐Ÿ“ What usually happens: โ€ข Engineering joins too late, after the idea and ticket exist. โ€ข Product returns too late, after the build. โ€ข The middle is a handover gap โ€” engineers build, product waits to see anything real for the first time. โ€ข Thatโ€™s where friction starts: product has solutionized, the business has committed, and engineering faces reality mid-build. โ€ข Everyoneโ€™s frustrated. Timelines slip. We loop back. Time lost.

Hereโ€™s the new flow Iโ€™ve been testing:

๐Ÿ‘‰ ๐—ด๐—ผ๐—ฎ๐—น (๐—ฝ๐—ฟ๐—ผ๐—ฑ๐˜‚๐—ฐ๐˜) โ†’ ๐—ถ๐—ฑ๐—ฒ๐—ฎ / ๐˜ƒ๐—ถ๐—ฏ๐—ฒ-๐—ฐ๐—ผ๐—ฑ๐—ฒ (๐—ฒ๐—ป๐—ด) โ†’ ๐˜ƒ๐—ฎ๐—น๐—ถ๐—ฑ๐—ฎ๐˜๐—ฒ (๐—ฒ๐—ป๐—ด+๐—ฝ๐—ฟ๐—ผ๐—ฑ๐˜‚๐—ฐ๐˜) โ†’ ๐—ถ๐˜๐—ฒ๐—ฟ๐—ฎ๐˜๐—ฒ ๐—ถ๐—ฑ๐—ฒ๐—ฎ (๐—ฒ๐—ป๐—ด+๐—ฝ๐—ฟ๐—ผ๐—ฑ๐˜‚๐—ฐ๐˜) โ†’ ๐—ฑ๐—ฒ๐—ณ๐—ถ๐—ป๐—ฒ ๐˜๐—ถ๐—ฐ๐—ธ๐—ฒ๐˜ (๐—ฒ๐—ป๐—ด+๐—ฝ๐—ฟ๐—ผ๐—ฑ๐˜‚๐—ฐ๐˜) โ†’ ๐—ฏ๐˜‚๐—ถ๐—น๐—ฑ (๐—ฒ๐—ป๐—ด) โ†’ ๐—ฟ๐—ฒ๐—น๐—ฒ๐—ฎ๐˜€๐—ฒ

๐Ÿ“ Whatโ€™s different: โ€ข Product defines the goal. Engineering explores whatโ€™s possible โ€” and they meet immediately.

โ€ข The ticket appears after POC code, once direction is agreed. No wasted planning on ideas that wonโ€™t survive.

โ€ข By then, we know whatโ€™s feasible, achievable, and roughly how long itโ€™ll take โ€” cutting downstream failure.

โ€ข The iteration happens early โ€” between idea, validation, and refinement โ€” powered by AI. What once needed major investment (time, design, development) now happens in minutes.

With AI, the biggest learning now happens at the idea and validation stage, not weeks later at build time.

Once we hit build, we still iterate โ€” but the loops are smaller, faster, and grounded in validated requirements.

โš™๏ธ In practice: 1๏ธโƒฃ Start from a business goal โ€” not a solution. 2๏ธโƒฃ Use AI to vibe-code technical options. 3๏ธโƒฃ Share a quick demo or screenshot โ€” no ticket yet. 4๏ธโƒฃ Validate: โ€œYes, that would solve my goal.โ€ 5๏ธโƒฃ Feed the discussion into AI โ†’ generate requirements. 6๏ธโƒฃ Build and release in short cycles โ€” fast, grounded, aligned.

This brings engineering upstream, turns developers into co-designers, and shortens the gap between idea and impact.

It wonโ€™t fit every project โ€” but for open-ended goals and discovery work, itโ€™s been incredibly effective.

๐Ÿ‘‡ What should we call it?

#AIEngineering #ProductDevelopment #RapidPrototyping #Innovation #AITools #EngineeringCulture #FailFast #TechLeadership