When In Doubt : Fundamentals
The fundamentals that I take with me on every engagement
I know exactly what I’m doing. Right?
It doesn't always feel that way. As a designer and product consultant, imposter syndrome and feelings of being in over my head is an ongoing battle. Why? Because clients expect me to know what I’m doing. All the time. They expect me to reassure them that I have a plan and loads of experience doing exactly what they need—what they’re having trouble with.
And, hey, I get it. They pay me (or my company) a lot of money to get it right…the first go round.
Often times, I’m brought in when there’s a gap in design or product capabilities—new product launches, innovation engines, product management uplift, strategic roadmaps…the list goes on. And there's usually a looming deadline or a peeved stakeholder who's already spent a lot of money on the wrong solution or team or whatever.
When I’m brought in the client isn’t paying me to guess, to not know how to fix the problem, and fail. It’s to make a b-line for the “W”—to win, and succeed, and fix.
Honestly, the expectation of success, all the time, is exhausting and stressful. It leads me to feel apprehensive about starting a new engagement with a new client, in a new space or industry, with a new team that has their own set of issues and problems. It leaves me thinking to myself
“I’ve never done this before. I have no clue what I’m doing or where to start.”
It can be a lot.
So how do I overcome all the worry and feelings of inadequacy throughout my 16+ years in the design industry?
I try to fall back on the fundamentals of what I know and what has continually worked for me in the past.
Focus on the problem and people
All too often, we find ourselves immediately working on a solution without fully understanding the problem we’re solving. Chances are, there’s a person who’s experiencing the problem and getting to know them a bit is beneficial to me and the client. Starting with the problem and the people involved also provides a chance to “reset and understand” instead of blindly building out a solution that isn’t rooted in a fundamental human problem. Sometimes, it’s hard to get a client’s eyes off of their thought out solution so asking about the problem we’re looking solve and for who is a great diplomatic way to examine an already-baked solution with a critical eye. It also provides a seam to open and recenter the engagement.
For problems, I use a problem statement framework to get the conversation going something like:
- Pain: Identify the pain that exists today.
- When, where, how: Define when and where the problem happens and any patterns that cause it
- Impact: Quantifiable impacts on the user and the business
- Importance: Urgency should be conveyed here
To better understand the "for who", I ask to see a persona.
What if the team doesn't have developed personas? Then I stress the importance for me, or someone on the client side, to take the time to do some research and build one (or validate what already exists). While I love personas firmly rooted in customer segmentation research, I try to keep in mind a persona is just another tool to keep me centered on solving for the humans at the other end of the problem. Something is definitely better than nothing.
Propose Experiments
As I mentioned above, clients don’t bring consultants in to try and fail. Or do they? Enter experimentation. Whenever I have a client that is apprehensive about trying some new process or implementing a new product feature, I always reassure them that all we’re doing is conducting an experiment in which there are two outcomes; to succeed and improve or to fail and try something new.
Changing the narrative to focus on experiments to improve is very helpful way to get around the whole “It’s not okay to fail" culture.
When building out an experiment plan, I like to include
- key questions we want to answer
- hypotheses to prove or disprove.
Once I work with the client to understand that, while experiments might succeed or fail, the learnings from either outcome is the important part. They will open up a whole new perspective on innovation.
I mean, isn’t product management just experimentation and hedging bets against informed decisions anyway? :)
Ensure there's alignment
One of the core reasons I like to start every engagement with a kickoff session with all client stakeholders teams is to gauge alignment within the business. Nothing will derail a engagement faster than internal client misalignment. A couple ways that I’ve found to increase and maintain alignment.
- Center on a person and problem. This goes back to my first tip. Know this; solutions can cause discord within a business—everyone has an opinion on a technology, group, or approach—but human problems are easy for everyone to get on board with. As long as we’re all targeting the same problems and people, the solutions will fall into place.
- Co-create. Need to gain alignment, build trust, and create rapport with your clients? There’s no better way than by taking the journey hand in hand through ambiguity and speculation to build, launch of a new product.
Ever come on to an engagement where the solution has already been pre-fabricated? Me too. I'm not a fan. Pre-fabricated solutions create a dynamic where alignment with them doesn’t matter. The client and I weren't able to co-create and we're starting the journey at different times—misaligned from the start. What I'm hinting at is they tell me what to do and I am expected to just...do it. Ugh.
Problems with alignment can also creep in when the inverse happens. If I were to build a solution in a silo, without client input and help, it opens up the doors for the relationship to turn into me presenting and the client"yay-ing" or "nay-ing" my solution (from on-high).
Both of these types of situations are enablers of misalignment so I ensure I’m bringing all parts of the business in early to collaborate and invest, aligning and centering on a problem and person, and co-creating with the teams throughout the solution build.
When everyone helps to create, alignment becomes an organic result of the product development process.
Don’t cave, Follow a process
I have been thrown into a lot of engagements. Some with crazy deadlines and expectations, some with teams that don’t understand the product development process, and some that are…well, set up for failure from the start.
Whenever I get the sense that my engagement may be a difficult one I like to double down and reinforce my design process.
- Understand: Problem, people, definition of success
- Create: Collaborate, design, prototype
- Validate: Test, measure, pivot accordingly
Through this simple process I have a lot of flexibility. It works great at the macro level but also can fit into other frameworks on a micro level. I can use it to run a discovery session, or to create a new product MVP, or even to build out a product strategy. Like I said, lots of flexibility.
What’s important here is that I have a process. It brings me comfort to know that I'm following something I've used and found successful with other engagements.
Now, my exact process is probably not the answer for everyone in every situation but by and large, it’s worked really well for me throughout the years and engagements.
But what happens when a client isn't familiar with my process and they push back?
In a perfect world, I'd lay out my process for the client and they would clap at the simplicity and brilliance of it, pay me money just for enlightening them, and call me back in for a bigger and badder engagement. In the real world, however, there are more reasons than not to abandon the process, put your nose to the grindstone and "just produce."
Believe me, I’ve heard it all.
From “There’s not enough time to restart from the beginning. We’ve got to get into market!”
To “We don’t have budget to test!”
And “We don’t have any mechanisms in place to measure or track progress. It would take forever to get that in place!”
There’s always a reason why it might be easier to forego a process. But for every reason not to do something, there's always a reason (or 10) to do something. I Point back to my process for success, I show that I'm flexible with it, and I can usually find a balance. It also helps when I reinforce that there is no additional work on their (the client) side and that I'll be doing all the heavy lifting.
So while a client might not immediately see the value in my proposed way of working, it's important that I educate them on how and why it works. I point to other projects and companies that follow similar processes. "Look at [competition]. They follow a similar process..." You get the gist.
In the long run, it’s always better to stick to something that I believe in.
Create feedback loops and measurements
Lastly, and I’ve touched on this a bit already, a great way for me to know that a product is headed in the right direction is to establish some feedback loops, and measure and monitor important activities, events, or key performance indicators.
By feedback loops, I mean activities like incremental customer testing and interviews, net promoter scoring, and customer satisfaction inquiries. Heck, even an in-app feedback widget can provide a bit of value. What's important is that I can get a sense of how we’re doing and if we’ve moved the needle on solving the problem we set out to solve for customers.
Another informative way to know if the needle is moving is to identify key performance indicators. Oxford's Dictionary definition of KPI: A quantifiable measure used to evaluate the success of an organization, employee, etc... in our case the "etc" is product.
The quantifiable measure could be something like new customers acquired, time engaged with the product, new sale conversions—there’s many that could be important. The key is to identify the KPIs, establish baselines of current performance prior to launch, and ensure that there’s a way to measure so that the product team can determine whether a solution (or experiment) is successful.
Gaining insights to customers through feedback loops and gathering important measurements plays a crucial role to help product managers determine whether their product launch or experiment is successful or a flop.
Customer feedback and metrics will heavily influence where to go next and how to continuously improve.
What's Next?
I've always taken my fundamentals with me but that doesn't mean I've got it all figured out. What I've laid out is definitely not a comprehensive list. I'm sure I've left out 1-100 various things that work for others.
At the very least, I hope this gets you thinking about your own ways of working.