In this episode, I give an overview of my PiCAA Framework, which is a framework I shared at my keynote talk for Netguru’s annual conference, Burning Minds. This framework helps with brainstorming machine learning use cases or reverse engineering them, starting with the tactic. Throughout the episode, I give context to the preliminary types of work and preparation you and your team would want to do before implementing PiCAA, as well as the process and potential pitfalls you may run into, and the end results that make it a beneficial tool to experiment with. 

Highlights/ Skip to:

• Where/ how you might implement the PiCAA Framework (1:22)
• Focusing on the human part of your ideas (5:04)
• Keynote excerpt outlining the PiCAA Framework (7:28)
• Closing a PiCAA workshop by exploring what could go wrong (18:03)

Links

• Experiencing Data Episode 106 with Jeremy Utley
• The Data Product Leadership Community
• Ask me a question (below the recent episodes)

Script

Today I will share my PiCAA framework with you, for imagining AI use cases within your business or product. This is an excerpt from a keyn

ote talk that I recently gave for Netguru, a software consultancy in Europe who

 runs an annual conference called Burning Minds. The framework was well received so I decided to turn the excerpt of that talk into an episode for you.

I want to re-iterate here that, while this is a creative exercise in solutioning, there are steps that should precede this. My guess is that you would most likely implement this framework as part of an ideation workshop or, as i call them sometimes, design jams. You’d have a cross-functional team involved which especially includes non-data people in it, and if you’re lucky, you might have a UX professional to help facilitate. 

So let’s talk about the environment for a workshop like this before we get into the actual framework you’d use to ideate.

If you have found UX design and research to be somewhat hand-wavy or opaque, these types of activities are precisely the types of work that design and UX professionals do, particularly in large organizations. A lot of the work is facilitation of cross-functional teams, allowing creativity to emerge, not getting bogged down in technical and implementation details during the ideation, and so forth. 

So, back to the steps that precede doing a PiCAA ideation workshop.  

First off, you need to understand the organizations business objectives at a high level so that after ideation, you can sort the resulting solution ideas by business priority – or at least, that is one axis to consider amongst others like  feasibility , datability as my past guest Nadiem calls it, level of effort, and value-potential.  

However, note that I did not say you should be discussing feasibility, datability, and other implementation issues during this ideation phase. It’s really important to take off these hats when entering the room and highly technical staff sometimes need to be reminded this so that you don’t end up debating technology during these sessions. 

The goal of an ideation session like this should probably be one thing: a large volume of ideas. That’s it. Not good ideas, or feasible ideas, just a quantity of ideas. 

And sure, don’t be afraid to invite ChatGPT in the room to contribute too! (See Ep 106 with Jeremy Utley from the Stanford D school on the concept of Ideaflow)

Secondly, there’s the human part of your ideas. This is where we stop talking about “the business” as an entity and rather, specific humans.  

If you’re regularly interfacing with your business sponsors/customers or end users, you’ll probably come up with better solutions that are intentionally biased towards problems they have. Now, you could argue that coming in totally green will help some new ideas emerge and that’s probably true. But, at some point, if you were to move these into a prioritization stage for potential entry into your backlog, you’ll definitely want to rank these in part on the human factors. 

For example, change management: how disruptive is the solution? Are you going to have to require multiple personas (i.e roles) to change how they work today, potentially in ways they do not like (even if the solution is “good for them” in theory)?  How usable does the team think they can make the solution such that it won’t be abandoned?

Whether you do this before or after your PiCAA workshop, this customer or user perspective is important to consider before you write a single line of code.

Anyhow, with all that said, here’s my excerpt from my keynote where I dive into this AI use case framework I call PiCAA. I’ll have a short wrap-up at the end.  

[KEYNOTE EXCERPT]

Ok, well I hope the PiCAA framework sounds like a useful creative activity your team can do if you’re in the stage of exploring AI or ML use cases within your business. 

By the way, as one of your closing activities of a PICAA workshop, you might also want to begin the discussion of  “what could go wrong” particularly from a human impact standpoint (not a project management or technical one). This is particularly true  if you are doing anything that involves your companies actual paying customers being affected by the solution:

• Black mirror testing and abusability testing
• Red teams / review boards
• DEI concerns
• For more on that, check out Ep 55 with carol smith who is an AI UX researcher 

Finally, I’m considering turning this into a workshop I give teams, or even creating a another self-guided course so you can do it yourself. 

If you’d find that valuable, shoot me an email at brian@designingforanlaytics.com 

Until next time, thanks for listening!