Every company has their own way of running client meetings – especially the first, crucial meeting with a new client. For any relatively early stage start-up, your first customers help define you. For tech start-ups, whose technology may change a little over the first few years of inception while figuring out product-market fit, your first customers aren’t just ones that help define your offering, they also help you understand where you can improve and what needs changing. Being a tech start-up and an open source project puts us in the privileged position of having had prior interactions with many people who later end up becoming valued partners and customers. Some of our customers have been with us since the very beginning, supporting us and giving us feedback on how and where we could improve in order to provide a product and service of real value.
At TerminusDB, we like to really get ‘stuck in’ – as we say – building with and supporting the customer. This involves not just creating a good rapport, but also understanding the use case, and how and where TerminusDB or TerminusX are going to help and fit into the picture.
Introductions and GCIQ
The philosophy behind our client meetings is similar to that of our internal discovery sessions – you can read more about those here. Someone from our team would first have an initial interaction with the customer to figure out the main goal of the project – this would usually be our co-founders along with one or two other members from the technical team. We then schedule a longer (usually 3 hour) session with the customer and their team.
We begin this session with a quick introduction – which, in typical TerminusDB fashion, involves answering a candy question – followed by a GCIQ activity. For those unfamiliar with the concept, GCIQ stands for Goals, Concerns, Ideas, Questions. We like to set these out clearly before starting a project so we know that we’re all aligned and on the same page.
Job To Be Done and How Might We
We might, in some instances – especially if it’s a very new project – approach it from a JTBD (Job To Be Done) perspective. There are numerous resources and reading materials available on the value of approaching strategy and planning through the JTBD framework – here’s an excellent one to start off with. A good JTBD statement encapsulates the context and problem a user faces, and the underlying motive for a particular product or solution. A good JTBD statement also helps the producers or designers better empathize with the customer.
Here’s an example of the JTBD statement we came up with when we started building CAMS (more on that here if you’re interested in reading more about how we’re helping nations become climate and disaster resilient!).
From this point on, there are different directions you could take, but we’ve found it useful in both our internal planning as well as planning with some customers to use the JTBD statement as a starting point for framing How Might We questions (more on that here). HMW questions are a way to start thinking more deeply about your project and a way to frame ideation. We’ve found it most helpful to stick to framing 4 questions that we believe really relate to the core of what we’re building. We then brainstorm ideas about how we might approach those questions/problems. After this, we prioritize the ideas we came up with in terms of importance and feasibility. While no idea is bad, there are always some that are more crucial and time sensitive, and also more feasible to achieve in a short amount of time (like when you’d like to get to an MVP quickly). What this also does is give us a roadmap of sorts and clear goals to work towards.
Tech Stack and User Journey
With some customers, we also find it useful to have a short session where we can understand and map out the tech stack they are already working with, to understand the flow and figure out where best our solutions can fit in.
Being a tech company, one of the things we’re most concerned with and always trying to improve is people’s user journeys. This also holds true for when we work with customers and our product fits somewhere in their tech stack – we still need to be sure that whoever is using the end service has a simple and intuitive user journey. So with many customers, we have found it useful to map out user journeys. For all of our customer related – and even internal – planning meetings, we use Mural as a collaborative whiteboard. The user journey not only helps us identify clear goals we need to work towards, but also helps identify any roadblocks or obstacles we may encounter from a development perspective.
Build a Schema and Next Steps
Regardless of the planning activities we carry out during the session, we always reserve at least 1.5-2 hours for coding and engineering work. We get a tour of the kind of data our customers might be working with and get started on building a schema. During this part of the meeting, we also actively identify next steps and keep note of them – this could be the customer playing around with TerminusDB more and sending on questions, and it could also be fixing certain bugs on our end. After the session concludes, we set up a private support channel (this may vary depending on the type of contract we have with the customer) for the customer within our community server where they can ask any questions they might have. We also look at scheduling a follow-up hackathon session about 3 weeks after the first session.
So that’s usually how we run client meetings at TerminusDB – every client is different though and while we have certain tried and tested (the GCIQ rarely fails!) practices, we always bear in mind what the customer needs and tailor our approach based on their requirements and goals. As always, if you have any questions about how we do things at TerminusDB or are interested in knowing more feel free to come say hi in our community server!