From Conversation to Code: Re-imagining an AI-Native Product Development Lifecycle for Enterprises

Sourabh Daroji at UXDX Community: From Conversation to Code and Research to Impact. Video: https://youtu.be/W3Fh2IcnVtE

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why the tools aren't moving the needle

[00:00:08] Hello. There are a lot of AI tools today which proliferate our workflow, and everyone is also starting to use them. At least at our org, it's been almost a year and a half since we tried to incorporate all these products into our workflow. But everyone also uses all these tools individually and tries to get some amount of productivity boost. As a whole, as an org, we don't see a big needle movement. For example, we're not shipping more features, or we're not shipping things at a higher quality. Why is that? That's the question I want to answer, and how, with a case study, of course, and how we at Nutanix try to deal with this.

[00:01:03] If you take one thing away today, it's this: AI is only as good as the context it has. The point of AI in our workflow is not faster tasks. It's faster shared understanding. That's especially very prominent in enterprise, because clarity is the scarcest thing we have, and the shared context is what unlocks both clarity and velocity.

[00:01:27] I'll walk you through a real experiment we ran. I'll keep coming back to some of these anchors that you see. One is to start from the conversation. Two is to turn talk into artifacts fast. And three is to carry intent all the way to code without losing it. It might not mean much right now, but over the presentation you'll see what it actually means.

[00:01:52] Let me make this concrete with a feature that we piloted this new workflow with, with AI coming in the picture, and how it disrupted our traditional workflow. App migration, this is one of our features. This has a lot of nuances and intricacies that one might expect at an enterprise company like ours. I'll not go into the weeds of it, but in general, if I were to describe it, it is to migrate whole apps from one place to another place, where place being compute resources.

Starting from the conversation

[00:02:35] We did not have a PRD or anything at all for this one, and we had to start from scratch. The PM, Samina, with whom I worked, she had an idea of what this was. So I'll just demonstrate how it went when I sat with her with this new workflow. I'll just show. So this is Notion AI.

[00:03:00] We sat in a room and started transcribing the meeting. She was bringing in the product perspective, I was bringing in the design perspective, asking all the whys and user-centered questions. We spent a good chunk of time discussing in detail about this feature. And in 30 minutes we walked away with a fully fledged PRD, initial PRD, of course, it needed some edits, with also user stories that the designer could later follow on.

[00:03:38] Let me just take a step back here and give more idea on what happened actually here. This is the first leg of the product development life cycle, where a PM and designer sit together and have discussions over time. What happened here was, to Notion AI we were able to provide our PRD guidelines and persona standards defined by our UX teams as context. Notion AI transcribed and processed our conversations, and the resulting artifact was an initial PRD with user stories.

[00:04:20] Again, you'll see the same anchors here: start from conversation, turn talk into artifacts, don't let anything go to waste. That's usually the case, we have a lot of meetings, decisions get changed, a lot of movement happens, but we kind of forget, since we work in silos, or everyone has their own working style or their favorite tool of choice. All of that is fine, but the important thing here is to provide the right context to get the artifacts and keep things moving.

From PRD to a clickable prototype

[00:05:02] The next leg is for the designer to iterate on their designs and to come up with initial concepts and such. For this, again, we used the initial PRD that we got from the conversations, along with the user stories, and we also provided visual design guidelines that we had, to Figma Make or Cursor. We use both of them. It's very easy to configure the context in either of these tools today.

[00:05:35] The resulting artifact was our initial concept, which was a clickable prototype. And all of this had cut down our six weeks of work into one week or one to two weeks of work. Here is a quick demo of the artifact that it created. One thing to note here is that it had captured all the nuances of the conversation and all the constraints that we were working with.

[00:06:07] This just goes to show that the context is what matters here. Instead of me going to Figma Make or Cursor and trying to give a blank prompt out of my memory, having this continuous flow, this pipeline of context, makes more accurate artifacts and also keeps everyone in line. This artifact actually helped us align quicker with the stakeholders, because they had something to see and it was more of a shared vision of what we were trying to go for. And if there were any glaring directional problems, that came out very quickly here. This helped us align better.

Carrying context into the handoff to development

[00:06:51] The next leg is between the designer and developer. The designer, me, I had to do some iterations, of course, since this was the initial concept. I did some iterations on Figma and handed off the screens to our developer. When I was handing off the screens to the developer, we also have this pipeline again. All of them in our org right now, at least, we are trying to make one place to maintain context. Part of that has been Notion.

[00:07:25] So our Notion has visual design guidelines, accessibility guidelines, content guidelines and UI patterns. All of this was provided as context to our developers. Along with the screens and these guidelines, these guidelines were translated to skills for Cursor or Claude Code.

[00:07:47] This led to them being able to create an initial production-ready UI. Again, one caveat is it's not 100% there, and of course that's not going to be the case, and that's okay. But it's a higher starting point than what a developer would have gone through. There's a lot of conversation and missed nuances that get lost if this part was not there and they just started from the screens on my Figma. There'll be a lot of pixel pushing and a bunch of conversation that might get avoided when we follow something like this.

[00:08:26] So here is a quick demo of what the developer, JC, had to do. He provided the Figma context here. Also, all of this has been made much easier since the Config announcements this year. But this is just a demo to show how carrying the context is what adds value with using AI in the workflow. Here you see some of the guidelines that JC has connected, and also the context of the Figma file.

[00:08:59] Once this runs, you will be able to see the screens, which are on par with what we expect as designers at Nutanix. This needs to be defined further, for sure, but the starting point again is better.

[00:09:17] What I'm trying to say here is, none of this worked because we added a lot of AI tools or anything like that. It's the context that was being passed between these tools, and being able to pass rich context is what unlocked the needle movement for us as an org. Rather than, yeah, we do use AI individually for our own work, but that only gives you incremental boosts of productivity. Here, as an org, we were able to move quicker, achieve clarity, and align on vague things much quicker.

What shared context actually means

[00:10:00] So let me be concrete about what shared context actually means, because it's two things. First, you encode your organization into the AI. What that means is you need to make skills, MCPs and rules, so AI works with the real constraints and nuances of your design system, your org, your coding practices, accessibility, content guidelines, etc.

[00:10:25] Second, you make every conversation count, and make every meeting, every decision become part of the context. Because we know, when we work with PMs or engineers, the context keeps evolving, the requirements keep changing, and the decisions keep evolving. So having a trail of that easily accessible to AI will help it make better artifacts for you to work on, rather than starting from scratch. And not just whatever one person remembers into the prompt. That's the part everyone skips, and it's where the compounding effect of using AI at the workplace is.

[00:11:14] If I were to imagine the workflow of the future, it's something like this. Imagine the workflow where context is omnipresent, the tools are connected end to end, and conversation to code is one continuous thread. Not like a relay race where the baton keeps being passed to the next team, or dropped, and it becomes a game of telephone[?] where the context gets lost.

[00:11:46] But I want to be honest about one thing. You cannot unlock this alone. That's something we had to learn. It's a team sport. Everyone, the PM, engineering, design, all have to work together. It's an open, collaborative, constructive loop that has to happen. Instead of us having to optimize our own little corner, we have to work together to improve the process as a whole. So don't try to boil the ocean. What we did was we ran a pilot with this feature, for example, and then slowly increased the scope to other features to try to do the same workflow, and then make it into a standard.

[00:12:29] Here's my ask, specifically for the designers in the room. Don't just adopt new tools. Try to push your org towards a shared context. Be the person who connects the conversation to artifact to code, because you're already the person who sits between all the three stakeholders and the process. And try to chase for the 10x workflow change, not just an incremental change in your personal productivity. And remember, again, AI is really good only as long as the context is good. So the thing you're really building is clarity, and that's where it actually boosts the productivity of the org as a whole. And that's all I had. Any questions or any thoughts?

Q&A

[00:13:20] Host: Excellent. Thank you very much, Sourabh. It was kind of nice to see somebody else's end-to-end flow, and particularly with some of the new tools that are coming in. As Sourabh said, if you have any questions, please do write them in on whichever platform you're watching this on, and I can put those questions through to Sourabh.

[00:13:41] Host: But I'm going to start with one, because when I saw it, alarm bells went off in my head, when you were showing me that artifact that you used. As you said, it was great for alignment, it's great for stakeholders to be able to see it. But there's always that risk of showing an early design, because that was relatively early in the flow. How do you manage that risk? And the risk that I'm referring to is that you're locking in too early on a particular style, or that stakeholders get too invested in a particular approach.

[00:14:15] Sourabh: At our org, what we did was, we were very aware of that one, that maybe PMs will get too attached to this flow when we show it, or something like that. So we had a clear conversation with the PMs, to educate them in the sense that, hey, what you're seeing is more of a wireframe rather than the whole picture or a direction. Think of it as one possible direction, to get clarity.

[00:14:44] Sourabh: And then, as a designer, you would want to go broad. Now it's even more convenient, with Figma's code layers and stuff like that, where you can branch off and create a lot of variations at once. So that's one of the ways we try to achieve this clear boundary of, okay, this is a wireframe, don't stick to it, it's not the final design. And just having that clarity with your PM, and again this comes with working as a team and being collaborative with the PM and understanding the role of AI.

[00:15:22] Host: Brilliant. I guess the other one that is jumping out: how much of the collaboration at this part of the flow is there with a developer, to just ensure that it's feasible? Maybe the database structures don't allow certain types of interactions.

[00:15:37] Sourabh: One thing I missed to show here was, I only showed you one conversation being transcribed and that being the source of the artifact. This conversation actually, in real life now when we do it for our features, it's like a compounding effect of, oh, I had a meeting with a PM, I had a meeting with engineering. It keeps evolving, and engineering will bring their constraints of, oh, our database only supports this type of queries, or something like that.

[00:16:09] Sourabh: So all of this compounds, and it's your job again to maintain that context. And tools like this, Notion for example, it automatically detects when I'm in a meeting and suggests, do you want to transcribe this? With all of these really good tools, it makes it easy for you to maintain that context. It's your job at your org to ensure that the context is maintained and passed to the AI, or passed to yourself if you want clarity on things as well.

[00:16:43] Host: Brilliant. That kind of brings me... everything I'm reading right now is all about how to give the AI the proper context, because the challenge with AI systems is they don't learn after they've been released. So all it knows is whatever is in its context window. How are you trying to manage that? Because I've seen a lot of people really struggling with trying to get the right context shared. I'd love to hear how you're deciding what to distill into this context and what's noise that isn't necessary.

[00:17:17] Sourabh: It's no different than giving context to a new joiner at your company to succeed in a particular feature. For example, we chose to give the persona certificate[?] that our research team did, because in general it is necessary for all our features to be designed for particular personas. So it's up to you. Imagine you had an intern and he or she was working on some feature. What would enable them to do it better?

[00:17:50] Sourabh: Just have that thought in your mind, and then list down, okay, maybe them following a design system later on, after their explorations, makes sense. So maybe when we are generating the final code UI, we should pass the design system as the context, or visual design skill as a context. And maybe initially we have some grounded research data. Maybe there is past research data that might benefit this feature. Again, having that thought in your head of the context, and making a list of things, and imagining, trying to empathize with the AI, I think that's the right way to put it. You can give the right context.

[00:18:31] Host: I have a follow-up question, but I think Julianne has written it better. She says, "Thank you for sharing your insights. How do you prevent outdated AI context or duplicate files from becoming a problem across the team, so you have one single source of truth?" And what I found from my experience is, it starts great at the start of a project, as you mentioned, "oh, let's link in this research." But that research goes stale, somebody links more research, and things grow organically over time. So how do you manage that?

[00:19:03] Sourabh: The easiest way, at least for me, is from the tool side right now, at least. So for example, with Notion, it builds on the previous conversation. This is a very typical scenario even at work for me: there's an initial PRD, and then there's a revised PRD that is a different document altogether, and they are two separate files. Which one is the source of truth? That's a question again.

[00:19:36] Sourabh: When we use Notion, it clearly understands. It goes by recency, and also conflicting data points and all that, and it has things like verified pages and stuff like that, so that you just have to bring in the authenticity in the document. That helps a little, for sure. But also it's more of a... you need to be aware of what is valid and what's not.

[00:20:05] Sourabh: The easiest way I've figured that out is, let's see. We do have, for example, for design system, we have different versions of the documents clearly maintained. So we provide the latest version of the document, so that it can refer to the latest guidelines and stuff like that. I think one of the core things that I would like to tell here is, again, the humans involved here are the people who should be held accountable for the richer context.

[00:20:41] Host: So there's no cheat sheet. It's the usual, somebody has to maintain that context.

[00:20:48] Sourabh: Yeah, yeah. And tools are great. I feel Notion, for example, is the tool that understands your previous conversations and how things have deviated. You can make an agent there that kind of also logs the changes at the top. So that way it can also be automated to a certain level, but again, I think you should supervise, for sure. Again, I think the context is the thing that gives you the clearest picture. So controlling that will control the output, for sure.

[00:21:24] Host: And you were speaking to me when you were saying we want to merge product, design and dev, because that's everything that we're about here. But in your flow you were talking about a PRD document that gets kind of signed off and handed, almost like a handover from PM to design, and then design do the design artifacts. So where do you see that kind of collaboration with context? Is there still handover with documentation, or how is that working? What's happening to those artifacts that previously, I guess in the old world, were kind of thrown across the wall?

[00:22:02] Sourabh: For sure, it has become more fuzzy nowadays. There's no proper "okay, this is where my line ends and this is where you start." It's a more organic... That's what, when we demoed the Notion transcription thing with our PM Samina, she didn't have a document either. It's both of us sitting together, and we just have a standard of, okay, this is how our typical PRD is, and this is how our research artifacts are, and using this you create these artifacts. Now it's like we share the ownership of the PRD, and it's more of an organic thing that evolves, and we define when it's ready for the next stage and stuff like that.

[00:22:53] Host: Okay, so you're still using the artifacts, but they're a more collaborative creation process.

[00:22:59] Sourabh: Yeah. Yes.

[00:23:03] Host: One of the other things that I'm struggling to keep up with is, the tools keep changing quite rapidly. You had thrown in a few things in there. I guess there's Notion and they've got their agents. You've got Claude, you had Cursor, you had a couple of other tools in there, and then there's Mythos being released, and there's 5.6, and everything is doing different things. How are you managing that in your process? Are you analyzing each new model and each new feature and trying to make sure that you've got the best flow?

[00:23:39] Sourabh: Yeah, we do that on the side, but I think the main part of the workflow right now is, again, to streamline the process of providing the right context at all points of the workflow. And the models are interchangeable at this point, I would say. For example, since Claude Opus 4.7 it's been incremental changes to the performance of the models.

[00:24:07] Sourabh: So I would say the focus should be mainly on how do you streamline your whole life cycle. Maybe for us Notion worked because it was more easily available and connectable with all the tools, but that could be different for different orgs. I would say all the models out there right now are pretty good. It's just a matter of connecting them together and being able to provide the context. So I would much rather focus on that part than keeping up with the "oh, this is the next model, this is the next model."

[00:24:42] Host: The one area where I'll dig in a bit more on that, because you're right, I agree with you. From a coding perspective, the models definitely are getting better and better, but they're good at the moment and yes, they'll get a little bit better. Design has been lacking up until now, quite recently. I think Fable has improved quite a bit in 5.6 as well, kind of a step up in design. So are you finding that you can incorporate design a bit better in those? And I know these models are a week old.

[00:25:16] Sourabh: I think it's the harness around Fable that makes it better. That harness can be emulated with a lower-end model. We also have to consider cost nowadays at our org. I tried Fable at my org and I had to change one button, and it blew through like 200 credits of mine. So that didn't seem feasible as an exploratory tool, at least right now.

[00:25:48] Sourabh: So we are trying to build harnesses around our workflows to make it give a better output. I would invest on that. There are really great skills out there for front-end design, UX design. These are really good to get at least the first thing out there which is more viable. The obvious problems with usability and all these are taken care of with something like that. So, incorporating and finding those tools: if you log into Twitter, I'm pretty sure your feed will be bombarded with a lot of tools. Try and find some of the good ones and make sure your output is better that way.

[00:26:33] Host: Brilliant. I think we're in our last minute, so I think we probably don't have time for another question. I just want to thank you once again for sharing. I hope everybody out there enjoyed it as much as I did. Thank you very much.

[00:26:48] Sourabh: See you.