I’m at Strata+Hadoop World for the first time as part of the data driven business day tutorial, and I got to present on requirements analytics. But this whole day is awesome, like a crash course in big data and the kinds of results it can get you. The schedule is here, and all presenter slides can be downloaded later (I believe).
In this blog post, I’ll share a few neat insights from the day, and how I tie them back to the product management/business analysis space.
To paraphrase Alistair Croll, who kicked off and moderated the whole day: We’ve built ourselves into a constant feedback loop so the machine can interrupt us more gracefully. The companies that have the best context have the best interruptions. And certainly there are lots of ethical questions about this.
Tie back to product management: We have to decide how we want the product to interrupt someone, what kind of context is needed to make the decisions, and we need to know the business rules that define the ethical boundaries – these are all requirements.
Farrah Bostic of Difference Engine says data doesn’t actually tell you what to do. There is an interpretive analytical layer that has to happen. “We think we can have all this data and make statistical inference out of these data sets,” but they have to be backed up on theory and understanding of root cause.
Tie back: We have to help define what question our users are trying to answer, and then understand what information and analytics will actually give them a reliable answer.
Farrah also suggested most marketing people aren’t familiar with statistics or rigor to the extent they need to be to get meaningful metrics that show what is working or not.
Tie back: I love this one because we have really driven our marketing organization to be metrics driven (kudos to Melanie @Seilevel for this). In the product management space, same thing – we need metrics for our products to define their success. And if we don’t have them, build the functionality into the product to get the data.
Brian d’Alessandro of Dstillery posed the question: Is bigger is better? Is the statistical power worth it? Doubling data doesn’t always double your benefit. Lots of people buy data. Few know how to know if they are getting value out of it. Data has value if using it generates more money than not having the data.
Tie back: This really gets back to objectives. Whether or not you know the business objectives of any IT implementation – be it big data, buying data, analytics, SAP deployments, mergers, etc., and does the value you expect out of that beat the cost to implement – simple ROI.
During an interview, Mark Doms, Under Secretary of Commerce for Economic Affairs, talked about how the government has high response rate relative to private sector on surveys (88%), but it’s dropping significantly (unemployment survey). The public trusts them to get high quality data, but that’s getting harder. They provide lots of foundational data to the public and let the private sector use it and build on it (like population data or weather data).
Tie back: this was mostly just interesting so I wanted to share it, but the part about how many survey respondents relates to elicitation with stakeholders. How do we know we have enough stakeholders during requirements elicitation? And how do we know they aren’t biased?
Nellwyn Thomas at Etsy talked about what they do with analytics. They start with who the users of the data are (product development, member operations, marketing, finance…). Then they decide on types of data – clickstream through survey as examples. When looking at a project team, Product Manager and Analyst are major parts of the team – as it should be.
Tie back: This is a great case study about how to do it right. Stakeholders, what data, and who will use it and how.
I’ll give you the punch line of my talk – focus on decisions made from analytics to drive and prioritize what gets built first. No one else here was using the word “requirements,” but they were all hinting at the same type of thing. They were talking about types of expected results (business objectives) and the need to understand “why?” users want solutions and metrics to look at or not look at.
Anyway, really energizing day!