I am the only internal Power Platform developer at ThriveTribe. No team to bounce ideas off. No senior dev to escalate to. Just me.
You learn something quickly in that setup. Technical skill gets you halfway there. The other half is knowing what to actually build.
And you only find that out by talking to people.
Everyone Has a Different Lens
ThriveTribe has a CTO, programme managers, operations leads, clinical advisors, and frontline staff who open Dynamics 365 first thing every morning and close it last thing at night.
Every conversation I have with each of them is valuable. But in completely different ways.
The CTO gives me direction. Strategic priorities, where the organisation is heading, what integrations are coming. That shapes how I think about architecture and what to build for longevity versus what to ship now.
A programme manager gives me scope. What is the process supposed to look like? What are the compliance requirements? What does success actually mean for this programme?
A frontline advisor gives me reality. What is the process actually like? Where does it break down? What workarounds have they quietly built into their daily routine because the system doesn’t quite fit the work?
That last one is the one developers most often skip. It is also the one that tells you the most.
The Things You Miss From a Distance
A while back I sat with one of our advisors and watched them complete a task end to end. No instructions, no leading questions. Just watching.
Frustrated clicks that went nowhere. A field they always skipped. The same button causing uncertainty every single time.
I went in expecting a feature request. What I got was more useful than that. The system was fighting them. Not in a dramatic way. In the quiet, daily, death-by-a-thousand-cuts way that never makes it into a support ticket but costs real time and energy every single day.
So I set real defaults so they stopped typing the same values into every record. Reordered fields to match how the work actually happens. Trimmed the command bar down to the actions they actually use. No new features. A few hours of work. The app felt faster.
That insight did not come from a requirements document. It came from sitting with someone and shutting up long enough to see what they were dealing with.
Why Every Level Matters Equally
It is tempting to weight the conversations differently. The CTO sets the agenda so that conversation feels more important. The advisor is just a user.
That framing will cause you to build the wrong things.
The advisor is the person your work has to serve. They are the ones who will tell you the new referral form is technically complete but has a dropdown that takes four clicks to reach when the work demands it be the first thing on screen. They are the ones who will tell you that a field you spent a week building is always left blank because nobody actually needs it.
The CTO will rarely know that. It is not their job to know that.
My job is to hold both conversations and build something that satisfies both. Strategic direction from the top. Ground truth from the people doing the work. Those two things do not always point in the same direction, and when they diverge it is worth surfacing before you write a single line of code.
What It Actually Looks Like in Practice
It is not a kickoff meeting where you collect requirements and disappear.
It is checking back with an advisor two weeks after a change to ask if it actually helped. It is being present enough that people flag things to you informally, not just through a ticket. It is translating what a CTO describes in strategic terms into something a canvas app can actually deliver, and then validating that translation with the people who will use it every day.
As the only developer, I do not have the luxury of specialising in just the technical side. The business analysis, the user research, the stakeholder management, that is all part of the role too.
The best thing I have built at ThriveTribe was not the most technically complex. It was the one where I understood the problem well enough before I started that I barely had to change anything after deployment.
That only happened because I asked the right people the right questions first.