In the world of products, time-to-value (TTV) is the amount of time it takes a new user to realize value from your product. The less the TTV, the sooner new users find value.
Think about the last time you downloaded an app and immediately hit a paywall after seeing just a bouncy splash screen with some vague promises. Annoyed, huh? That’s one of the bullet proof ways to increase TTV, and probably fire up some suspicion and reactance.
No one wants to spend a lot of time or effort setting up and learning a product that might not even do what it says.
Same thing goes with collaboration. People will be more likely to trust you and reciprocate, after you provide value.
In my first year of working, I had this idea that value comes from the tangible outcome. In my case, as a product designer, it meant that I needed to pull the curtain and present some mind-blowing solution in order for the team and stakeholders to get value.
Of course, that thinking was doomed from the get go.
There are a lot of crucial steps in the design process before problem solving, or better yet — before you should be allowed to think about problem solving. So, if we took this definition for TTV, stakeholders would need to wait for those solutions, in order to reach the aha! moment of your collaboration.
To put this to the blatant extreme, imagine someone taking your ideas and insights and then saying — ok, now just wait for me, I’ll be back with the solution for the thing you asked for. How can you not feel uneasy? Or a little suspicious?
Ok yes — some part of the value is going to come from the final tangible outcome, but the collaboration can’t afford to wait until that moment for trust to be built. And frankly, it’s not like people are going to wait for the end result to decide if they can trust you.
When the discovery phase of the design process kicks off, your objective is to gather the necessary insights about the problem space, the as-is-scenario, the objectives and the constraints.
On the one hand, you are facilitating stakeholder and expert interviews, running discovery workshops with them — and on the other, stakeholders put in the effort to provide you with insights about the vision, prior user research, how things work and general previous efforts.
So in the reciprocity dynamic — at this moment — you are receiving the value you need in order to proceed with the next steps of the design process. Besides your professionalism and good energy, there is a risk stakeholders may feel like they are giving more than what they are taking at the start.
Of course, if people have good faith they won’t make any fuss about it. However, just like there are things you can do to better your user’s experience, there are things you can do to better your team’s and stakeholders' experience.
Whenever you start a project in a domain that you ‘re not familiar with, participate in meetings, talk with stakeholders and actively observe the words, phrases and acronyms that people are using. Write down anything you ‘re not sure about. Do a deep dive on everything you noted down in order to get a good grasp of the processes in the domain.
If you learn to use words that your stakeholders are familiar with in your day-to-day vocabulary, they will know you have done your due diligence to understand the work they do. Not only will this help you overcome miscommunications, but it will build up trust that you are aware of the nature of the problems you ‘re asked to solve.
The less you are trying to align between point A — which is when the initial insights about the problem are shared from the stakeholders — and point B — which is when a solution is proposed back to them — the less probable it is that you reach consensus from the get go.
Even if you think that you ‘ve caught on quickly and you are “inside your stakeholders head”, take collaborative steps. Facilitate a design process where stakeholders can contribute by participating in problem framing workshops, observing in usability studies or simply seeing playbacks from the discovery methods you are running. In this way you can validate you are aligned in terms of objectives and progress. Moreover, people are more likely to value the methods and outcomes if they feel they partially contributed to them.
At each point of the design process, make sure the team and stakeholders are aware of the current progress and what the next steps and milestones are. You may be fully aware of everything that is happening, both front stage and behind the scenes, but you need to remember that stakeholders are on the outside looking in. So, whenever you kick off a project, structure a roadmap with the team, confirm consensus and share it in a common reference point that everybody can access throughout the project.
Roadmaps aren’t just a kick-off documentation — they are your source of truth for the project’s plan, and you want to make sure they are always up to date. Also, having a visual representation of the plan is a major plus, because the more the team sees how close they are to reaching a milestone (e.g., completing a task, reaching a goal, etc), the more motivation they have towards reaching it.
Of course, documentation is just documentation — you can’t expect teammates and stakeholders to check the roadmap 24/7 in order to uncover any updates. Never let stakeholders feel like they are dealing with a black box. Be proactively verbose at each note-worthy progression point. Remember to always wrap up by highlighting the next important steps. That way you can ensure there is a clear sense of direction for the team.
A great collaboration is based on respecting’s peoples’ time and attention in all accounts. When you are running discovery workshops, presentations or just posting through Slack, remember that people are taking the time and attention and focusing it on to you. Set clear goals and frame the needed outcomes of an activity, in order to know whether it’s necessary to involve somebody in the process. Also, it really never hurts to ask — try to uncover more about people’s day-to-day, their preferred communication style and available band-width in order to decide how you want to approach your communications with them.
When you do need to involve somebody, prepare the context-in and context-out of the process. If it’s a meeting or workshop you want them to participate, share an agenda prior to the event, so that people have a clear image of the discussion topics and outcomes. If they need to do more than observe, inform them early on so that they have plenty of time to prepare. During the activity, make sure to follow an efficient timeline to hit your goals and respect the initially discussed time estimation. Finally, always close the activity with a wrap up of the outcomes and next steps, so that people can get a sense of completion and mentally cross it off of their lists.
Similarly, if it’s a post or email, provide context and specify the ask in a concise way. I know sometimes enclosing all the necessary information in 1–2 phrases can be difficult — but try to avoid lengthy paragraphs. If people cannot skim through your message they might feel like they don’t have enough mental capacity to open the context, and put it into “snooze” mode.
Again, remember to wrap up threads to provide that sense of completion.
Even though people aren’t necessarily going to notice the value — it’s not like you can say “hey, notice how I’m respecting your time and attention” — doing so lays the groundwork for efficient communication which is the no. 1 key to build trust.
This post is actually a first iteration — ok, I mean first readable — so in case you want to contribute with your feedback on the ideas send it my way on Linkedin.