Sometimes you do it by user interviews, sometimes by paper prototypes, there&#x27;s a huge grab bag of options. My peers who focus on product and design would be better at telling you their magic, but from what I&#x27;ve seen it&#x27;s deep and broad and the results are often surprising. We&#x27;ve saved customers a <i>lot</i> of money by discovering that wanted to build something that their customers didn&#x27;t want to buy.<p>From the engineering side, my role is to make development fast enough that product and design can find out whether they were right by having something in production quickly. This obviously varies according to project. For a highly gatekept ops culture, I could have something in an acceptance environment in hours that takes days, or weeks, or months, to reach true production.<p>But sometimes we get true CD and a team of designers and engineers can put tested code in front of users the same day, and have meaningful metrics shortly afterwards.<p>On my first project we had a hard, immovable 6 week deadline. We had a path to production after 3.5 weeks of pushing to get through complicated deployment hoops. Once we had the path to production our product manager and designer were able to perform laser-focused surgery on our backlog in the final weeks. They knew, sometimes within hours, what changes were being used and what had not worked.<p>It was a real eye-opener for me. Still a standard I hope for on any project.