How to :: Handle client’s objections¶
Client’s objections are omnipresent during a project¶
Leading a project the Toucan way is also about constantly asking for feedback :
- Do the user stories fit user needs ?
- Is the app design adapted to its end users?
- Do collaborative features match to your expectations?
We create an environment where your client can express their need, be listened to and offered solutions. And that’s precious ! Client’s objections have to be welcome because there are healthy. By expressing their frustrations, needs, and positive & negative feedbacks, clients allow us to grow, and to improve our Product and Methods.
What client’s objections are usually about?
- The Product itself
- The Project Management
To lead you project efficiently and to position yourself as a Toucan Toco expert, you need to know how to answer these objections. The few examples below will help you making clear how you manage a project for your client’s own good, and what the Product does and doesn’t, aligned with our best Dataviz principles.
How can we adress these objections?¶
On the Project Management¶
I’m sorry but I can’t read the story / I don’t see the Datastorytelling in your application 1 - Remind context : It’s only the first iteration, the app might not be very homogeneous, but we’re here to try to bring more consistancy and fluidity to the navigation 2 - Remind your role and ask for their help : We are Product Experts, and sometimes we do need a stronger support and inputs from our client, especially on the Business part, to co-build your application. Datastorytelling is about succeeding the collaboration between you, the client, and us, TcTc/partners 3 - Offer them a quick fix to improve the navigation : implement linkTo to better link stories between themselves, use commentary / reco / tuto to ease the navigation / re-work the stories naming with the client to follow their end-users habits, etc
Why don’t you do any on-the-fly calculation inside Toucan Toco? 1 - Remind the philosophy of the tool : It’s the proper self of Toucan Toco, we tell stories, we guide users inside stories, so we write the stories upstream. That implies defining upstream all the calculations, aggregates. Also please bear in mind that Toucan Toco is a dataviz tool, not a data exploration one 2 - Explain how easy it is to do it your way : Calculation are made upstream to get better display performances inside the application. It’s actually for your own good that we do such thing. Data are pre-agregated and stored into our mongo base. Easy right? 3 - Offer them alternative solution : on external bases (SQL for example), it would be possible to do on-the-fly calculation but it would also depend on the base reactivity, on the volume of data treated in the query : anticipate the display performance you’ll get at the end by doing most calculation upstream !
We’re getting to the final delivery meeting but we’re not ready and the app doesn’t bring us a entire satisfaction, there are still changes to implement, the app is not complete If the client expectations is different from what you’ve realized, you have to go back through the historic of the project 1 - Get back to the roots : Remind your clients that the Key Success Factors you’ve defined together during kick-off are meant to guide this project to a global purpose. The final delivery is the achievement of this global purpose, but it doesn’t end the life of the application. That’s just the beginning ;) 1 - Remind project background : Show that all feedbacks communicated by the client have been prioritized and integrated :) List the evolutions you’ve brought to the app, list the new ones, hierarchize them, and bring the Sales into the discussion to adapt the project perimeter (add another iteration to the set-up for example) 2 - Offer compromise : Act that the perimeter of the additional iteration will corresponds to the app final delivery 3 - Think of the future : Target rapid autonomy for a client who have a moving/growing perimeter OR offer Premium CSM offer or TMA 4 - Remind your performances : Remind the rythm of the projects when leaded by Tctc, the amazing time-to-market and the possibility to realize evolutions/upgrades on the application pretty soon 5 - Ask for internal help : If your client is asking for product evolution, ask your Tctc Dev/Technical interlocutor, and organize a call with a member of the Product team
The “final delivery” meeting might scare some clients, because they’re affraid that everything will happen at once and that they will not have any possibility to amend the application afterward. But that’s not true ! Tell them about the “Project Journey” and the upcoming “Deployment meeting”. You will plan it 7/10 days after the final delivery, so you can have the time to make the fine-tuning needed. You’ll present them their very final app, and help them getting ready for the app deployment.
On the Product¶
You’re not kind to develop the custom features I want, that’s not very agile to me 1 - Agility is action : For us, being agile is the ability to think of a problematic at any time, and implement the most valuable actions. We talk about actions, not about sepcific tooling, ceremony or rituals. 2 - Agility doesn’t mean rushing : Agility is not about flexibility or rush. It’s complicated to implement valuable things very quickly, because quality needs testings, and takes time. At Toucan Toco we’d rather take the time to do the right things to have a stable Product and offer great apps, than doing quick & dirty unstable work everybody will regret 3 releases later ;) 3 - Focus on creating value : the value generated by our agility has consequences on the Product, AND consequently help your clients to get the best answer their needs. Ex : « We are not going to implement YYY, because it doesn’t help to the success of the project/the product. We’d rather implement XXX, that creates more value, for both your app, and the Product »
The application has many bugs 1 - Define a bug : “it doesn’t work the way I want” is different from “there is a bug”. Remind them that you are the Toucan expert, and that to be considered as a bug, a feature/chart must have a anormal behaviour, different from what’s expected 2 - Ask for material : to attest that a bug is real, you need to be able to re-produce it on your end. To do so, your clients have to give you all the conditions in which they’ve observed the “bug”. That is to say :
- Device (laptop, smartphone, tablet) and
- Browser and version (ex: Chrome on Windows 75.0.3770.90)
- Url of the story
- Description of the expected behaviour and of the anormal behaviour they get 3 - Give them visibility on next steps : Some issues can be easily fixed. You can try fixing it during the meeting, so they can see how super reactive you are ! And remind them our “Zero bug policy”: all bugs that prevent the normal use of their application will be handled and fixed by our amazing Dev team as soon as they speak ;)
About the Studio : it’s not that easy - why is it not automatic? 1 - Studio is beta : it means that the end-user experience is guarantee and absolutely fine, but that the conceptor experience is still being improved. That’s why you may feel like some steps are not straight forward - yet ! 2 - We focus on pedagogy : Our Dev team is working very hard on the pedagogy offered to conceptors in Toucan Toco, to ease their experiences and their work with the Studio. We’ve added placeholders to help your understanding of the parameters, implemented
autocompletefor Mongo/Postprocess steps in code mode, and we focus on constantly improve the awesome doc you’re reading right now to make sure it answers all your questions ! 3 - Please share your feedbacks : When you touch-base with your favorite Delivery/CSM, you have the opportunity to give them feedbacks on your experience as a connector. Please take it ! They will make sure to share the information with the Product team, so they can prioritize the next development that will be part of the next Product Release. Just for you !