Why Your Process Needs to Be Adaptable

Last week I had 3 customer meetings the same day, with 3 very different customers.

The first meeting was with a conservative client who we had been talking to for weeks as they asked 1000’s of questions about our product and our process for implementing it, supporting it etc.  All fair questions in my opinion, and some of those questions were “what happens if 500 people all do ‘feature x’ at the same time?“.     That told me they were more risk adverse and liked the perceived safety of well thought-out plan. They also got into some low-level details that I didn’t think mattered at this stage, but I was happy to indulge and answer their questions.

The second meeting was with a customer who is a lot like me.  Likes action, speaks her mind, doesn’t beat around the bush and moves very quickly.  She hand-drew the UI she wanted for her iPad app, emailed it to me and within 15 minutes we went through all 15 or so screens to finalize the flow and information we would display.

The third meeting was with a customer that we had recently launched an iPad app for.  We were starting phase 2 and were talking about some of the updates we had made to our platform.  This meeting was somewhere in between the other two.  We went into the right amount of detail, IMO, and wrapped up somewhere between the time the other two meetings took.

In all 3 meetings, we reached tangible action and in all 3 meetings I adjusted my tone and language for each situation.  In the second meeting, for example, I had no problem being blunt and direct because I knew that customer would appreciate that more.

I have a “process” for how I build our apps, what details I need from the customer and I adjust that based on the customers needs.  If they need more documentation for some reason, I’ll make it and re-use it for the next customer who requests it.  If they want to work with hand-drawn mockups, I’ll work with that.   If I feel managing them through the building process will be like herding cats, I’ll change my language and use phrases like “I’m concerned if we don’t decide on X we’ll risk missing the date you want the project live”.   I find that’s a helpful way to ground customers who are spinning off into ‘what ifs’.

As I was driving home from work I had an ‘aha’ moment from PSL about that day.  I remember near the end of PSL, Johanna Rothman had stuck around giving a few of us more advice about how to bring PSL back to work the following week.   We talked about how to use what we learned about types and temperaments as a way to understand ourselves more and how we intake and process information from other people.  MBTI isn’t a theory used to label people, it’s never about that other person, it’s about you.   I found that having an understanding of myself helped greatly in these meetings.  It also helped me ‘get a feel’ for how I could change my tone, messaging and questions I asked for each situation.  Never once did I try to get them to change in order to fit them into a process.

I believe what I described is pretty basic customer management and this translates to whatever software development process you use.   The first Agile Manifesto value is ‘Individuals and Interactions over Processes and Tools‘.  Use your process as a guide, not a set of rules that you can’t deviate from.  I remember consulting for a company that had been using Agile for years and I was shocked how many times I heard “we can’t, our process is…“.    You’ll build a great deal of trust with customers by having an adaptable process and that will make it easier to live by the other 3 values.

The key is to find balance, if you’re working on a feature that has many unknowns, plan more frequently and in smaller timeframes.   It  may sound counter-intuitive but in that case, you’ll want to plan less.  Sometimes you’ll need mockups or more detailed requirements, sometimes you might not need any at all.  Once you understand the process you are using, you’ll be knowledgable enough to break the rules, when it makes sense, and realize that software development isn’t a linear and repeatable process like building toasters on a manufacturing line.