I’m convinced you can learn something new every day. Recently, I listened to a talk given by a doctor at Northwestern Memorial Hospital (No, I’m not considering a career change – I don’t even like stitches let alone the thought of cutting into someone). During the talk, I learned a great deal about problem solving through the lens of a patient coming into a clinic for the first time with some type of complaint (e.g. cough, fever, etc.). To me, it seemed very similar to helping clients develop applications. My takeaways were:
1. Whenever assessing a client, make a problem list that is as specific as possible.
This is basic brainstorming prior to meetings. For example, if a doctor knows you came in with a cough, he or she knows that the cough might be a symptom of 15 different problems with an increased or decreased probability. It might be allergies or something more serious. Similarly, when approaching clients who “want an app” write down every possible solution before the meeting. Think about features, ideas, and possible solutions. Write down complexities. You won’t code every idea or run into every problem, but this can help facilitate conversations and contribute to flushing out requirements ahead of time.
2. You can learn a lot about a client by looking at their “medications”
Do your homework. In the same way a doctor can tell your medical history based on your medicine cabinet, you can tell a lot about your client by looking at their websites, press releases and reviews. Therefore, you need to research your client. If your client is a publicly traded company, see what they’ve been saying in the news or in last quarter’s earnings report. Find out their customers and business cycle. Learn who their core competition is. This information will help you navigate the initial meetings and lend to credibility. The more you know ahead of a meeting, the better questions you’ll be able to ask.
3. Know Your Biases – the Three A’s
Everyone has a bias—even (maybe: especially?) developers. The goal is not to push out your biases but to realize they are there as an option but not the silver bullet. The danger with biases is that you might not consider a better option because you go with your “tried and true” method. For a doctor, it might mean a misdiagnosis. For a project team it might mean a less innovative solution. Here are the three A’s of biases and tips for using them to your advantage:
- Availability or “Easily remembered prior experience explains new situations you are facing. “ Information sticks with each of us differently. Certain ideas or methods will be in the front of our mind regardless of other readily available information. This just means you need to think outside of the box and be open to new ideas. Just because a method worked in the past doesn’t necessarily guarantee it’s success in a different scenario. It might, but it equally might not.
- Attribution: We naturally “invoke stereotypes in our minds and “attribute” negative characteristics to the stereotype.” For example, we hear “lung cancer” and think “life-long smoker” when that might not necessarily be true. In the app world, we need to recognize our knee jerk reactions and process these with our clients. It’s easy when you’re the expert to cast off some suggestions, but pushing back on negative stereotypes will help us provide the best solution for our client. Further, we might find our problem solved with an unlikely solution.
- Anchoring: Anchoring is when we seize the first solution, idea or functionality and “anchor” our mind on it. Maybe it is voice integration or a certain layout. We think it is the perfect solution and nothing else looks quite right compared to it. However, if we’re anchored to the idea, we risk missing out on the actual right solution.
As I listened during the talk, (and when I wasn’t Wikipedia-ing the diseases he was referencing), I was struck by how similar our jobs were: we want to diagnose an issue, provide a solution and make it work for our clients. I walked away, not only with facts about autoimmune diseases but helpful tips on doing my job as an analyst even better.