2019

5 things a dashboard should be (and 5 it really shouldn’t)

At Data Monsters we talk about Dashboards a lot. You probably hear them mentioned in business (and technical) conversations at work. Often it’s slipped into a sentence “We need that in a dashboard” or “Can we set up a weekly dashboard for the sales results?”. Many people use the term Dashboard to mean any display of data – even if it’s 50 rows in a table!

5 Reasons Data Warehouse Projects Fail

I have worked on data warehouse projects in many different environments for over a decade. None have been perfect. Issues I have seen range from cubes that take 12 hours to refresh at the end of every month, to business requirements changing so much that the data warehouse was scrapped before it was complete (and sometimes, with a new data warehouse project starting immediately afterwards with the new requirements!)

There are many reasons why data warehouse projects fail, here I look at a few of them.

It Takes Too Long to Deliver

Designing and building a data warehouse is not something that will be completed in a few weeks. It is a huge investment for most businesses, and it is unreasonable to not provide some of the benefits sooner rather than later. If it takes 2 years before the business users see any value from the data warehouse project they will have lost interest, or worse, they will have come up with their own ad-hoc reporting solutions in order to answer the questions they have about how the business is doing.

A phased approach is the sensible option. The project should be broken into smaller chunks. This allows something to be delivered to the business sooner, rather than waiting for the complete data warehouse. This obviously requires some careful planning, and it often seems counter productive. It might take three years to build a bike, then a moped, then a car – rather than two by building the car straightaway – but the impact is huge. Stakeholders are more engaged because they can easily move from A-B quicker on their bike or moped than on foot, even if it’s not their dream car – yet.

Lack of Support from the Business

Building a data warehouse is a slow and expensive process. Just because the decision-makers approved at the start of the project does not mean that they will continue to support the project. If they don’t start seeing results they will rapidly lose interest in the new shiny data warehouse that is costing them a fortune. It is important to keep people from every level of the organisation involved in the project.

It is tempting to sit in a corner coding all day, but that is the worst thing you can do. Keep other areas of the business informed of your progress. Everybody in the business should know the high-level goals of the project.

I have worked on teams that refused to let other areas of the business look at the data in the data warehouse – what were they thinking?! The data warehouse belongs to everyone!

Not Involving the Correct People

Designing and building a data warehouse is not just a technical project. Well before any code is written people from all sorts of areas should be involved. It is a business project and understanding the business need is the first priority. The business should be screaming out for a data warehouse, not a team in the IT department suggesting to the rest of the business that there is a need for one. A successful data warehouse starts with understanding what questions people will be asking of the data. Not just today, but in the future too – the data warehouse should be designed and built alongside the business strategy to ensure that it will be relevant in the future.

Data Quality Issues

Much of my experience of data warehouse projects has been in the financial services sector where the business users demand that the reports coming out of the data warehouse are 100% accurate. If a data warehouse is delivered to the business that does not reconcile with other, trusted reports you might as well hit the delete button immediately. It is crucial that reconciliation and testing takes place at every stage of the data load. And, get your hands on those trusted reports that already exist, and use them in your reconciliation process, or prove them wrong!

Lack of User Engagement

The data warehouse is only as good as the decisions being made by the business users relying on it. If nobody is using the data warehouse it is a failure. Most business users will be wary when the data warehouse they have heard so much about finally arrives. They will require training – this is a new way of talking to the data for them. Training needs to use business language, not technical jargon. When users do become engaged make it easy for them to throw more questions at the data warehouse. Adding requests for new reports to an ever-growing backlog is not going to satisfy the curiosity you have just encouraged. Make sure you offer a self-service solution too, where users can create their own reports.

As a developer there is nothing more satisfying than seeing the product of months of work being used as intended, especially if that product is helping the business be more profitable. Keep an eye on how the data is being used, ask people what decision they are making. Show as much interest in the product after it has been delivered as you did when it was being built – you will learn loads for your next data warehouse project!

Definition of a Data Monster

Jo and I decided to set up Data Monsters after a visit to SQLBits in April this year. It’s one of the friendliest conferences out there, it’s informative, in-depth and fun. But it’s missing the Data Monsters…

5 ways data can help product managers be f*cking awesome

A product owner is crucial for the success of the product – it must be a real commercial success – and by this I mean it needs to deliver a great customer experience, a great user experience (they’re not always the same!) and make money. Ideally, lots of money. That money might be made immediately and quickly, or it might come at some point in the future, but ultimately, the product needs to be able to sustain itself and be profitable for the business (and any investors.)

One of the hardest things we have to do is balance delivery of an exceptional user experience, with shipping a product and making money. Ship too soon, and anyone who downloads the app may not use it, or worse, will think it’s awful and tell the world. Ship too late, and you’ve missed the chance for valuable feedback, and your competitors may gain the first-mover advantage. It’s tricky, but that’s part of what makes the role so exciting and adrenaline filled!

In my view, the biggest tool you have for success is your data. And I don’t mean looking at the odd Google Analytics report and thinking you’re doing ok, but really interrogating the data you have, understanding what it’s telling you and acting on that insight appropriately.

Here are 5 ways data can help you as a product owner:

Data empowers you to lead

Your job is to lead the team to deliver a successful product. It’s also to communicate your vision for the product (the what), how you’re going to get there (the how) and crucially, what it means for the business and the customers (the why). Data helps you define and design this. It means you can make the right call when there’s a choice. You must be able to effectively model “if I do x, then how likely is Y outcome” and “of these three options, which one will make me most money” and you can’t do that without sufficient data to interrogate. Get hungry. Talk to customers, Plug in any one of the amazing and often free tools out there to help you understand what’s happening. Listen to your sales team – they’re out in the market. Read trade or consumer press. Attend events. Mix qualitative and quantitative data together to help you make choices. If you don’t have a product yet, you can do pretty much all of the above, with the exception of product data. And you must if you and the team are going to succeed.

Data backs up your arguments with evidence

It’s really tricky sometimes. You trust your gut, you’ve relied on it for years, and you get a feel for the right direction to take. But when it comes to choosing between route A or route B I have always found that being able to point to the data will help. Remember though, this doesn’t mean just looking at evidence that backs up your point. I’ve found the best way to do this is to adopt the “I’m right till I’m not” and “I want to prove myself wrong”. Test, measure, learn, repeat is important here. Find holes in your arguments, play devil’s advocate with yourself, and use “what if” analysis when you can.

Data validates and proves your business case

So your plan is to get your company – or investors – to spend lots of cash on development. To do that, you’re going to have to prove that they’ll get that money back somehow, someday. Your argument has to be believable. We’ve all seen (and laughed at) the “before” hockey stick graphs that bear no resemblance to the cliff-shaped chart that follows at the “after”. Don’t risk losing your credibility by being unable to back up your arguments. And yes, this means the numbers too. Know them inside out. Imagine it’s your cash you’re spending, your life savings. Or your house is being remortgaged to fund it. Get it right, use the data.

Data motivates the team

There is nothing worse for a good development team than feeling like their work has no impact, or being told nothing at all. It is your job to communicate the impact – hopefully positive – that their work has had, and data helps you do this. It could be as simple as sharing customer feedback you’ve had on social media. Charts showing progress on usage or engagement or other key metrics can really help motivate the team. I think it’s always worth ensuring the developers understand the commercial goals and constraints too. They will naturally want to do things perfectly, but often if they understand why you need it this sprint, not next year, they’ll find a way to achieve the same result more quickly. To do this they have to understand what that end result is. Allow them to be creative, and show them their work makes a difference.

Data helps communicate your vision and roadmap

Without a real vision for the product you’ll drift and so will your team. And that’s really not good enough. You need to be really good at communicating the same vision and roadmap in different language depending on who you’re talking to internally. For the senior management team or investors, this means “This release means the product will make X in recurring monthly revenue by Y and along the journey we’ll also improve our NPS by Z points”. For salespeople, this means “The next release will mean your customers can work twice as fast on X task and save Y hours per week”. For customer support people it means “This release will fix those top 10 bugs you hate, and the pages load twice as fast”. For all of these statements, you need data. What do the financials look like and what is this based on? How do you know what you’re doing is what customers want? How do you know they’ll like your alternative user journey? How do you know what the top ten bugs are? How do you know how fast the page loads, and that this actually matters to more than a few noisy customers?

In summary, data is the best and most precious tool in your kit. Use it, maximize its potential. Interrogate it, learn it, and love it. Be a Data Monster!