BTW - in listening to that podcast I found a lot of parallels with database design. whenever I'm asked to design a database for an early-stage system (I work i

BTW - in listening to that podcast I found a lot of parallels with database design. whenever I'm asked to design a database for an early-stage system (I work in early stage tech ventures), I ask the following: - what are the questions that this database should answer for you? How are those questions supporting your business goals 3,6,12 months out? (I'm trying to get to the business requirements here) - who will be asking those questions (I'm trying to put together some user personas in my head) - how frequently will they be asking these questions? corollary: how often will historical data be needed? (I'm thinking hot vs cold and complexity of retrieval, minimally required performance) - how much data to we anticipate is needed to answer the questions (this is really tricky in new ventures - often the answer is more data than what will actually occur in practice in the first year)? - finally, what systems & tools are people using to ask the questions and be notified of events? (I'm thinking about interfacing, apis) its all an attempt to stay very focused on the questions and business drivers and the people who use the answers.