Developer Journey
Understanding the base layer of the developer journey and where a specific product fits along that journey is valuable for products directly serving developers.
Some companies live along this journey, and GitLab is an example, although I hope many motre come along.
Understanding this j ourney and the personas who go along this journey helps apply focus.
New opportunities emerge when soething disrupts the flow or the space in which developers need to work.
So to me, being able to bucket that journey is important.
What could some of those be?
Onboarding
The onbaording part or top of the funnel is often generic across tools, but cannot be ignored; and finding a way to streamline this can be valuable.
Developers starts with tutorials, stack oerflow, hackathons....maybe they start with Docs if the docs directly address something they already know they are looking for (e.g. I need to support a billing solution; I need to integrate)
Onboarding milestone is Hello World: what does it take for me, the developer, to reach an early win that solves a problem.
The second part of the onboarding experience is conceptual framing: what does it do, how does it owrk, does i tsupport my mental model?
Conversations here can be around various API design pattterns, or an understanding of the data flow and format, or a high level architectural foundation to what and where am I deploying this thing.
The other major area of consideration is a simplified environment -- which needs to be both simple and bespoke.
Some are VIM-heads, visual studio, or anhthing in between and around.
What is the local development environment that someone can bootstrap. Painful is the environment that needs lots and lots of set up. beautifulu is a single brew command and you're done.
The second phase would be a various stage of build.
HOw can this be incorporated to solve the existing problem quickly. This can include proper SDKs, scaffolding, templates, APIs able to test right away either via browser or Postman client.
Then the workflow should be the full cycle of what they need to do based on their role and job.
For example, the deelopment needs of a data engineer will differ from that of a front end developer.
The needs of an enterprise developer on legacy systems will differ from that of a finance system or a smart contract developer.the needs of a performance engineer will be different from someone building mobile.
Within this, the phases are fairly well known: build, ship, test.
The other and last leg of this is maintain and refactor. This is part of the build, debug, ship and test phase.
A great answer will dive deep into one of these parts of the user jounrye based on insight or experience you think that allows someone to dig into the proble.
Example:
In the blockchain space, the front end developer who works with blockchain data has one critical criteria: fast iteration of indexing of that data, which often isn't local, to a front end.
If the indein r process takes a long time, then being to refresh the browser to see if something that looks right from a schematic perspective comes out right on the front end is valuable.
So problems that shrink that time to close to 0 for front end development solve their primary problem before getting to production.
The pain should also be prioritized when going through the journey.
But my point is, have a baseline of the core journey. Similar to how the core GTM funnel for nearly any traditional SaaS or consuer product is typically awareness, activation, engagement, retention. There are nuances in those, but if you start with this high level user journey for analyzing most software products, you can dig in.