Moving from Philosophy to practice

As a short reminder, my data science philosophy can be boiled down to five main points.

  1. Meet the needs of the end user (Our focus here)

    a. Any solution must be the minimum to meet their needs

    b. Any solution must be delivered on a timeline that is reasonable

  2. Understand the User

  3. Involve the User

  4. Understand the Environment

  5. Impact > “Cool”

    a. Don’t just think about “sexy” technology

    b. Ethics Matter

It’s important to discuss how to move from abstract philosophical tenants to the reality of implementation. I’m going to spend the time it takes to explain how I implement these points in practice. Hopefully, this is actually helpful for someone instead of just some high-handed moralizing.

Meet the needs of the end User

Since we want to provide the minimum to meet their needs, we need to first understand their needs. This is both simple and complex. Indeed, there is a lot written on the subject of going from the specifications given by a client to delivering a final product. At the end of the day, to me this means you have to have in-depth conversation(s) with the client to ensure you really understand what they need. I was chatting with a friend once in a different data science class who shared they were forging ahead with making a machine learning model for a small business client. His feeling was there wasn’t much value to be derived from that as the visualizations they had produced along the way were likely to be more impactful. It’s important to understand that sometimes simple is better for meeting the needs of the user. This requires a very clear understanding of their needs to make sure you actually give them what they need.

Part of this, is that you need to actually deliver what they need when they need it. That’s why delivering the minimum viable product is so important. If you spend too much time trying to deliver a complex solution, you may leave them in the cold. To avoid this, you need to understand the timeline they need a product in. This goes back to meeting their needs.

Actually meeting their needs (& understanding them)

Now how the heck can we manage this? It’s not quite so straightforward as it may sound. For myself, I’m perhaps overly fond of the power of conversation. While I am quite aware of the over-meeting phenomenon (an old idea to be sure; see “Will There Be Donuts” by David Pearl), I feel there are things you can’t get except through a conversation. I saw this as someone with some social difficulties.

My advice here is rooted firmly in the precepts of contextual inquiry. To that end, I believe the main goal is to get at the lived experiences of the clients/end users. This involves coming up with a set of environment specific questions. In general, I’d say this list of questions should cover most of what you need.

  1. What question are you hoping to answer or problem are you hoping to solve?
  2. Why is that important?
  3. Who are the stakeholders (who will be positively or negatively impacted)?
  4. What is timeline this is needed on and what is the priority level?
  5. How does the client fit into the organization (politically, org structure, etc)?
  6. How does the solution sought fit with the client and the broader environment?

This is just an idea of the sorts of questions I’d keep in mind as you get started. Ideally, if you can cover this in a half-hour, I’d do so but definitely don’t let the meeting last longer than an hour. Think of this as in in-take meeting. Don’t talk about what you can do at this point. Make sure you reflect on their needs. Throughout the meeting, practice active listening and don’t be afraid to ask questions. Most of the time, people are happy to answer questions or correct you if you’re getting something wrong. To me, this is where soft skills show their importance.