This message was deleted.
# product-management
s
This message was deleted.
b
Thanks for writing this, @Jeremy Hartley! And I subbed looking forward to more 🙂 One thing I've experienced is that the discovery questions and approach is formed by the constraints of the organization. For example, my experience is that platform teams rarely have excess capacity and the department always has a top priority or two, so general discovery questions are rarely valuable since every one already committed to working on things. But, value comes because they usually overcommit and need to trim, or don't have enough definition and need to figure out what exactly to build. I'll usually scope my discovery questions in the context of the priorities to see how I can best impact them, or how I can help resolve some resource deadlocking at the team levels that I mentioned above. Of course, this could just be a product of the companies I've worked in, and in other companies the more general, broad line of questions are impactful.
But a good developer interview starts with the goals it should accomplish and I think you did a great job when it comes to broad discovery.
j
Thank you very much for the insightful comment @Ben Voss (and for subscribing 😊). I think you are 100% correct that platform teams generally have full backlogs and often don't have time for general discovery. I still think that there is a lot of value in doing an exercise like this from time to time. In my current role for instance, I did an extensive discovery exercise recently. What I was hoping to find out was that we needed to further build out our Internal Developer Platform (IDP) and make it very easy for developers to e.g. add storage to one of their microservices. What I found out in reality was something very different. I found out that what were killing my developers were a number of issues related to the release process and the ease of developing locally. This led us to significantly shift priorities.
b
Very cool -- well done!