The Identify act is crucial for figuring out what you want to solve and why. Asking questions is the way to go. Below are some generalized examples. The successful outcome of the phase is to have clarity about what you wish to solve, why it needs solving, how do you plan to solve it, how is it being solved already (if it is) and (ideally) what data backs up your decisions/answers. Talking about data… Data is a two edged sword. Ever since it became “mainstream” the data point has bene used, overused and abused. Data is important but data alone cannot solve anything. It matters how it was collected, what makes you trust it, does it hint/point to something non-obvious, how/who is interpreting it. Sometimes people tend to hide behind it Use it as an excuse for/against given decision (or lack of any). Can’t stress more on the latter. There’s a thin line behind good, data driven decisions and bullshit like “What data backs you up?”. Last but not least, the Identify phase is the “fiefdom” of Product Management and Architects. The place where both roles must use their skills to the best of their abilities and lay the foundations of what is to become… something…
Given our context, image sharing website, let’s assume we don’t care about the data, validating the problem, why is it a problem or anything else. We just want to have the damn site and this is it. Later on we will see why this is not the “best” approach.