Design, Requirements, and the Low Code, No Code Wave in Product Development

Ryan Purvis: [00:00:00] Hello, and welcome to the Digital Workspace Works podcast. I'm Ryan Purvis, your host, supported by our producer, Heather Bicknell. In this series, you'll hear stories and opinions from experts in the field, stories from the front lines, the problems they face and how they solve them, the areas they're focused on from technology, people, and processes to the approaches they took that will help you to get to the scripts for the Digital Workspace inner workings.

Ryan Purvis: so welcome Matt to the Digital Workspace Work podcast.

Ryan Purvis: yourself and your company, please?

Matt Genovese: Sure, Ryan. Yeah. So my name is Matt Genovese. I the background I heard some of the other guests have gone back to when they were kids and I thought, oh, man, but that's the truth for me too. And you know, I did. Start all the way back then I was a child of the 80s.

Matt Genovese: I guess I'm I'm considered Gen X through and through. I was working on the Commodore Vic 20 if anybody remembers that. And then the [00:01:00] Commodore 64 and I grew up on a farm so we didn't have any other. There was only one other kid around that was my age, but outside of that it was chickens and cows. And so my parents said, you know, go learn how to use it.

Matt Genovese: So I taught myself basic and then by middle school, I was doing assembly language on it and learning about interrupt routines and how to, write all kinds of fun things at the lower level. And I really enjoyed it. I knew that when I grew up, I eventually wanted to work in, technology in some way.

Matt Genovese: And this was back when I was, you know, 11, 12 years old, I guess and then fast forward I had gone to university for computer engineering at a school called RIT up in Rochester, New York, and then came down and worked for Motorola and I, I guess the, the funny story is that I had as a kid, I remember seeing the.

Matt Genovese: copyrights for Motorola on the Commodore 64 is a copyright 1977, I believe for Motorola, because the main processor inside that Commodore was a Motorola chip. And I thought, you [00:02:00] know, I really like the Commodore. I maybe it'd be nice to work for Motorola one day. And it turns out after going to school and going down and moving to Austin, Texas, I worked for Motorola and unbeknownst to me, I ended up working for the design manager on the original 6800.

Matt Genovese: Processor that was the, architecture for the chip that was in my Commodore. So I, I kind of came full circle that way. But then I, I worked about half my career in semiconductors and hardware. and then I, I moved over into software working in, in various roles in, product management.

Matt Genovese: And what I found was that I'm you know, having a background that goes all the way down to the ones and zeros was really helpful. Because I, I never, I never really liked the idea of a black box. You know, it's useful sometimes to have models where you don't have to care about what's going on inside.

Matt Genovese: But for me, I always wanted to understand what was happening below, you know, under the hood and then under that hood and then under the hood below that hood. Right. And so working in [00:03:00] product it was easy for me. To start breaking down problems and figuring out how is this going to work and what are the challenges and what are the tradeoffs even thinking down to the, to the hardware level.

Matt Genovese: And so if you fast forward, I, started a company called plan around the design focused on design and requirements of software. And where our claim to fame is, is that we really do think through as much as we can up front in terms of planning and requirements to try to understand where the challenges might be, think through those, do the an ounce of prevention is worth a pound of cure philosophy and, and understand as much as we can.

Matt Genovese: And then do the UX design and the documentation, the user stories, test cases, so the development team can execute. And that's what normally. For our clients sets us apart because we're enabling all the downstream teams to execute efficiently and have what they need in terms of documentation so they can pick up the, pick up the baton and run and execute and do so.

Matt Genovese: And, and you know, in turn, get features out the door more [00:04:00] quickly and save money in the process. So I think that's in a nutshell what I, my background leading up to today.

Ryan Purvis: Great. I mean, I got lots of questions. I mean, what are your thoughts and maybe just a sort of one diagonal, I guess. What are your thoughts on the low code, no code world that's starting to grow up?

Matt Genovese: Oh, interesting. Well, there have been low code for some time, and usually that's a trade off between Flexibility and, and by the way, flexibility in parentheses, flexibility with future expandability and that then you're trading that off for speed to get something to market to test it out.

Matt Genovese: So I think in the end you have tended to pay for the success later on by. Having to rework an application or just regenerate it from scratch. If you've, if it's been in, you know, some web environment that was used to create it because it's just not scalable and it can be scalable in terms of performance or it can be, you know, scalable in terms of what you can do with it, right?

Matt Genovese: 'cause you're kind of boxed into whatever framework they, [00:05:00] they provide you on that low code. Again, you lose flexibility. However, I'll say that with a, a lot of the, work that has been done with language models and development that has been assisted by language models. I think we're moving quickly towards a day where it's not going to be low code as much as it will be.

Matt Genovese: You don't need to code as much and there'll be a level of automation. So that this drawback of inflexibility will not be an issue anymore. And that the code can be written for you based on a good specification, based on if you supply good requirements the work can be automated, I believe, in the future such that the build will be happening to a large part by the AI.

Matt Genovese: And probably assisted by developers too, but the, what that means is that the cost. We'll come way down, probably to the place where you have these low code frameworks today.

Ryan Purvis: Yeah, well, mean, I'm glad you went the route you went and it was a bit of a loaded [00:06:00] question. Because one of the things that I'm involved in is a low code, no code platform that generates the code for you.

Ryan Purvis: Well, so what we're doing, which is, I suppose, the one approach is we're taking the giving the user the ability to create their interface using widgets. So drag and drop the widget that you want.

Matt Genovese: Yes.

Ryan Purvis: that's the no code part of it.

Ryan Purvis: So you drag on whatever, whatever widgets, greetings, widgets, whatever it is. But let's say out of the widget stack we have, you still want to do something that requires a little bit of HTML or style sheets or whatever it is, you have that ability as well. So that's where the low code part comes in.

Ryan Purvis: And then you can bubble up the bubble up the data model that exists so you can get to a field that's in the data model. And with the the other thing we're doing is we're allowing you to group The widgets together to create your own widgets. So you have that, you know, very much like in PowerPoint.

Ryan Purvis: You can group things together, but the generative power is that when you drag. We did on and you save the page that generates all the back end code to do whatever you want to [00:07:00] do and specifically how we're approaching it is for fintech. So when you drag on your check my balance widget, whatever the app builder person who's building their business has signed up for for the accounting, I think for the back end as a service, it'll have the API in place to go and do that.

Ryan Purvis: So you don't have to worry about doing all that stuff. And that's really the, you know, making making API as beautiful as is one of the slogans we've been playing with

Matt Genovese: all very clever.

Ryan Purvis: Yeah, not my wording. I'm too much of a Neanderthal to come up with stuff like that, but it does make sense because, you know, if I look at all the stuff, I'm sure you would say the same thing, but, you know.

Ryan Purvis: Whenever you go and build an application, building the UI part actually can mostly be the easiest part sometimes. And I say that with a bit of a bit of commas because it's only when you start running into the technical challenges and the integration problems that you start realizing that some of the UI things you thought you were going to be doing will have to behave differently.

Ryan Purvis: There might be a different sequence, might be some compliance, there might be some regulation. One of the things that we do by building the platform like we have is we take care of the [00:08:00] compliance and the regulation. so in the case of doing a transfer or a bank payment in the UK, there are certain screens you have to have.

Ryan Purvis: So you don't have to worry about whether you have those screens or not. So when you go drag it all out, it'll generate those things for you. Same as when you do an international transfer, there'll be different things, and it'll be different per regulation, you know, jurisdiction. but what I, what I like about what you're saying is that, and this is the thing that we, we might actually talk about this on a side thing, is that one of the things we struggle with customers is conceptually.

Ryan Purvis: They've never built the app before they've never built the web interface before, so they want, they always wanted designer to come in and build that for them. Now we can show them examples and we've got different flavors and the rest of it, but sometimes is that conversation that consultative approach to tease out what's experience you want.

Ryan Purvis: What are the things you're trying to achieve? What makes your app different to the other guys? And I don't know what your thoughts are on any of this stuff, but I welcome your experience.

Matt Genovese: Sure, no, I think it's a, I understand where you're coming from. It's a very smart, clever way of attacking the problem of [00:09:00] business logic to handle the APIs and so on.

Matt Genovese: So you don't have to get involved in that. In that set of work. And you're looking at it certainly in FinTech from a compliance point of view but if you generalize it to any application you've got not only compliance, more or less, depending on, the area that you're within, but just business rules in general that you have to adhere to UX design and requirements and the work that we do at Planorama really focuses on that, front.

Matt Genovese: I'll say before the engineering. Begin before the development begins to understand what are the pain points? What are the jobs to be done? What are the problems that customers have? How do they think what is their mental model? And then. You have to incorporate, certainly from the other side, you certainly have to pull in technical limitations and boundaries, compliance, you know, and you, you mux all that together into a design that satisfies the needs of the user, right?

Matt Genovese: And various types of users. It's not always one type of user. There's many types of users, including ones that [00:10:00] are not the primary is like administrators, customer administrators, even from the customer side or internal administrators and customer support, right? All the different rules you have to think through all of that capability and as well address performance issues, technical limitations, again, compliance.

Matt Genovese: And at that point, when you've. you know, almost like in MATLAB, when you have multivariable equations and you finally find the local min or local max, when you found that optimum point at that place, now you're ready to actually start doing some design work to map out screens that you can test with users of different, of these different types and de risk all of that development to come.

Matt Genovese: So. I'll agree with what you said that these low code frameworks are great for addressing certain issues, but the UX and really, you know, backing up to a larger level. The requirements is the bigger issue. And once you understand that, then. Mapping out the screens and what people tend to think UX is just pretty pictures or making it look nice, you know, which is such an [00:11:00] oversimplification of the issue, you need to get to the place where now you can tell the other teams or the low code framework or whoever is involved in the engineering what to actually build.

Matt Genovese: I've heard it said, I think it's a good way to think of it. Although it's not a it's not a hard and fast rule, but engineers are typically really good at building products, understanding limitations of the products, but they rarely get into the actual pain points of the customers and users and really understanding that.

Matt Genovese: So you can build. A great product that nobody wants to use right? And there's, there's lots of instances of that happening. There's graveyards of that, but you know, technically it's really the, it's a beautiful product when you look at how it was written and the extent, you know, extensibility of it. And then it just goes off.

Matt Genovese: You know, into a graveyard because it never really got to be successful in the marketplace.

Ryan Purvis: I'm laughing because there's a product that I've had a good long history with called SysTrack. Made by Linkside Software. And you know, it's a great product, but it's a very technical product. And it's a product that you would [00:12:00] use to monitor your desktops to do root cause analysis, monitoring, all that kind of stuff.

Ryan Purvis: And I'm laughing not because there's anything wrong with the product. I think the product is a great product. It's one of the reasons why I endorse it so much. And there's actually a lot of good products in this space, to be fair, Control Up and a few others. But. these are products that unless you're a technical, like built by a technical person for a technical person.

Ryan Purvis: So when you meet that person who really gets the data, they love it. They're like, Oh, this thing tells me everything I need to know. But when you take it to a business user. it's like, I don't know. I can't even get to get in energy. It's like put him in the in a horror movie with, you know, they just don't want it.

Ryan Purvis: This is complicated. There's too much information. You know, just tell me the simple answer. Do I need to buy two screens or one? But it's one of those things where you need to have. Like, I think, you know, in that case, it does the job it's supposed to do. I mean, there's definitely usability issues with it.

Ryan Purvis: The value of something like that is when you get abstracted and aggregated to the simplest thing, and often the sort of conversations I have are like, and it ties it back to the objectives. What are you trying to achieve? And then trying to find the data point that matches that and then to tell the [00:13:00] story.

Ryan Purvis: And the reason why I'm bringing that up is that I think. Often, and I think it's becoming much more common now, when people build software, they're no longer building it very functionally like they did, you know, the sort of you know, the old waterfall approach, you know, whatever, now Agile has come along and everyone uses it, now people hate Agile, they're going back to sort of something else, I don't know, but I think when you can get to the ability to sketch out the story of what you're trying to solve with the product you're building, and almost break it up into those little pieces Nuggets, you know, like almost like I always, I kind of get using the analogy of a companion of short stories to build the product.

Ryan Purvis: that's a good place to be because then you can, you start getting the marks for the people that are going to use the tool in different scenarios, but change the data.

Matt Genovese: That's right. It's it's a, you know, there's a term that's often used in UX design and product design called jobs to be done.

Matt Genovese: It's a very easy term to say, because everybody gets it. You know, you go into work during the day. You go to do something. You have certain things [00:14:00] that need to be done certain jobs to be done and those. To some degree, become the short stories in your vernacular that you're using right where I have to accomplish these things.

Matt Genovese: And here's the reasons why. Here's what I'm trying to accomplish and sometimes every one of those will map into features. And sometimes you just sit back and you realize, oh, we could automate this whole thing in a different way, right? And make it that much better. as long as the user. Has the mindset in order to be able to adjust because it typically in UX design, you're trying to mold the application to the user's mindset.

Matt Genovese: So you don't want to have to make them, you know, wrap their heads around it. That's what it used to be, by the way, in the 80s and 90s, right? All that training was required and you just, you know, I remember so many times I was when I was in high school, I worked for the school district that I, I went to.

Matt Genovese: And I worked with teachers, my teachers. I'd go and help them learn how to use the different software or the mainframe tools. And it was always sit down like, Oh, I got to figure out how to get, I got to get my head around this. I got to understand how to do these things. And there just wasn't this sense that [00:15:00] the application can be made.

Matt Genovese: To be easier to use. It was always the frame of mind that the user had to wrap their heads around it. It was a tool because computers were new, right? and then later on, did was there the sense that, oh, you can, you know, there's ways that you can make the software easier. And this is what, when I started learning about UX design, you know, later on in my career and realizing that this was really part of.

Matt Genovese: Yeah. Of requirements, right? If you let engineers sit down and build the software, they will build it so they can use it because they're the ones that have to use it and test it, you know, including the QA folks. It doesn't mean that the actual that the, the end customer. That doesn't mean it was designed for the end customer to be able to use themselves.

Matt Genovese: It just means functionally. It's correct. And I've gotten pretty good by the way at figuring out when applications were built by developers or designed by developers because it ends up being the. You know, variations of the database put on the screen, you know, with a big submit button, right? [00:16:00] And then that's the easiest to do, right?

Matt Genovese: Take what the user typed in, do some validation on it, and then just paste it in the database table. There you go. And that's easy to QA, it's easy to develop, but it's probably not the optimal experience the user by any stretch.

Ryan Purvis: I worked for a bank. And we had a form built in service now to remove a piece of software from your desktop.

Ryan Purvis: It had something like 27 fields to fill in and and, you know, we replace that with one click button. And the irony of that 27 fields is all the 20 except for maybe one field. All that information was information we already had. So we knew who you were. We knew all that stuff, but they made it was very complicated.

Ryan Purvis: And that was the perfect example of a technical person had built this thing because that's they understood what they needed to do the thing. But because of whatever reason, they couldn't get to the data at that point. So they built this complicated form. And then, you know, you've got 130, 000 people having software installed on their desktop that they don't need.

Ryan Purvis: And you're paying for licenses. So the cost [00:17:00] of that decision was never felt by anybody, but when you start realizing that when they start clicking the remove button, I can't remember what the stat was, but I think like the first day we had like 10, 000 removals just because they can press the button once.

Ryan Purvis: And you know, it's just an exponential number for what you're saving for the business. There was something I wanted to ask you. I mean, what, what is your approach when you engage with a new customer? Whatever scenario it is, I mean, how do you take it with them? What your starting points and where do you try to get to in a period of time?

Matt Genovese: Well I mean, our approach, , every customer is coming in at a different place. Sometimes they're building a new product or sometimes they're extending or, adding onto an ecosystem of existing products. they may have a A mature process internally, or they they may not right. So we have to come in and have some initial conversations to understand where they're at and what their challenges are.

Matt Genovese: Realistically, our entry point is to smooth out the rug for them in terms of their process from customer requirements to development. That's often where I see the struggle[00:18:00] for many companies is that they, have a process that is either not getting features out quick enough.

Matt Genovese: It's costing too much. They're having to do a lot of rework. Customers are not happy with the product on the whole. And so after we understand those challenges. And it doesn't take long to do this is not a 6 month, you know, consulting arrangement to figure out what all their problems are. Okay.

Matt Genovese: We're not coming in like, like 1 of the big consulting firms. we then start thinking through. Okay. Well, given where they're at today, maybe we have to go and talk with some customers, existing customers or perspective customers. Users start assessing where some of the challenges are. If it's an existing product we may normally we're working alongside their product manager.

Matt Genovese: And somewhat of a consultative role to help them as well with their work. But, you know, after we get started executing, we're trying to, you know, understand where the challenges are in the design, the current design or start creating a plan for a new design. If it's a new application put together a priority list of what needs to be tackled next.

Matt Genovese: Some kind of scope [00:19:00] that we can all look at and put our heads around. We even built a tool. Ourselves called Sinfonia, which is a tool for capturing scope and thinking through and ensuring that we have elaborated the requirements in a way that everybody can see and understand. And then we start execution.

Matt Genovese: And sometimes that execution it most likely it's going to be mapping out some diagrams and understanding who's using the system and what they're going to be doing with it to address these certain jobs to be done or these features that need to be built. And then we, we use that time of discussion and collaboration to ensure that we're going to be designing the right thing to de risk our design work coming up front.

Matt Genovese: And then finally, we go into the design and create the high fidelity UX and UI design. Sometimes we're creating prototypes that can be that are clickable that look and feel like the end application. And the user, we can put them in front of actual users or customers and get feedback on them before any development has ever been executed.

Matt Genovese: And then when we de risk that, then we go into the, to the design the [00:20:00] design work. And that comes with the full set of designs, the user stories, test cases. And that's where the development team uses our output as their input effectively for their sprints or whatever methodology they're using.

Matt Genovese: And then they execute from there. And we try to establish a lot of feedback loops and touch points so that we're all on the same page during the whole process. And again, if we follow that, we find that there's very little trip ups, you know, people are given what they need to be successful on the product development team.

Matt Genovese: and then everything just flows more smoothly out the door.

Ryan Purvis: Yeah, I mean, I think you're answering a you solving a core pain for lots of lots of people? And I'm thinking about customers and work that I've done in my career, where one of the biggest problems is just trying to be clear on what is the, let's call it the minimum viable product, what is the next version of that look like?

Ryan Purvis: and what often happens, and I'm guilty of this too, is that Yeah. Yeah. You know, in your mind, you can see version one, version two, version three, version four of what you want to do and getting the sequence right. But then when you're talking about it, you kind of jumped to [00:21:00] version four, forgetting that you've actually got to start with version one.

Ryan Purvis: And then what ends up happening is you build the skyscraper or the rocket ship. And what you actually needed was the VW Beetle to get you from A to B. And yeah, it's a tricky one. And I'm very interested to see this tool that you've built because you know, I've sort of built my own management tool for this stuff using Notion.

Ryan Purvis: Which is a great tool to begin with because it's nice and flexible. It's like Excel, but a little bit, but whatever, I don't know if you've used Notion. And I find that with the combination of Miro boards. Is it quite a nice way to sort of better, but it's definitely not the solution. I think it's a nice stopgap.

Ryan Purvis: curious to see what your product for your internal product. Maybe it is. I don't know if you want to send it to the people yet, but it looks like

Matt Genovese: well, it's the I'll tell you the idea came from. I've been doing this for some time and managing product requirements area and I started realizing this was years ago that I'm You know, a lot of the tools that I have seen were project management oriented.

Matt Genovese: They're always moving along time. You know, Kanban boards and things like that. Jira is made to be this. But what I [00:22:00] didn't see was something that would help me to manage product requirements, you know, even to the point where I could say you know, I want to outline a scope. And then break that down in at multiple levels, you know, say, take a problem and break it down to a set of sub features or challenges or features, however you want to define it, and then break that down even further.

Matt Genovese: I ended up having to use drawing tools to do this. Yes, exactly. And then when you look and say, well, but I want to link those things to user stories and to test cases and to other types of documents at the time that just wasn't available. So I, it was a lot of manual. It was a lot of a manual process. And when I started thinking about the issue, it was that I couldn't house the requirements in a cohesive place because all the requirements were typically were spread out in different physical locations and there was not a level of granularity that I could find where I could say, Hey, you know, this, this block on this user story map or feature map is not really a user story.

Matt Genovese: That's actually a piece of acceptance criteria, right? For another user story [00:23:00] that exists later on. And to be able to have that fine grained control of linking objects together, what I realized, this is a big graph. It's a giant graph. And being able to traverse through that graph as a product manager, as well as a designer or developer, had a lot of value.

Matt Genovese: Because what I also learned was that developers, they never go back to the, well, I don't say never, but every developer I've spoken to, yeah, I'm going to be careful. I'm on audio but every developer I've spoken with said, well, they want to find out how it's supposed to work. They go to the code for a given feature.

Matt Genovese: They don't go to the spec because they think the spec is out of date. Right, but what if the spec wasn't out of date? What if the spec was up to date and easily traversable? So you go to a graph and you say, okay, I'm looking for this particular feature. I found it on this particular feature map or or the part of the road map and it was finished then and I can jump over and say, okay, what users can use this?

Matt Genovese: Okay. What types of data does this touch? What are the things that are available? All right. You can start traversing down a path. [00:24:00] Of these objects effectively that allow you to understand at least the intention of what should have been built, you know, now, whether it was built or not, that's ultimately up to the company.

Matt Genovese: And I think there are some ways to even address that and keep those in sync. But that was the problem I was trying to solve, not only for product managers, but also for developers and designers, anybody coming into the project or, you know, the project is big enough where you just can't capture it all in your head, right?

Matt Genovese: But you have to be able to traverse through and the code, while it may be the correct. I mean, it ultimately is what is is out there in production. Probably it is not the fastest and easiest and I think best way to to navigate what the feature spec is for your project. And certainly not for anybody who isn't a developer, right?

Matt Genovese: Designers and product managers are not going to go through the code. Typically so what we, you know, it was an offshoot of what we do a plan around because we write the user stories. We write the test cases. And we create the designs and we do all of this and we deliver it to our clients in their own [00:25:00] systems, right?

Matt Genovese: Whether it's a juror and usually a confluence and, you know, we try to write really structured and organized documentation. So this was an actual path. We said, well, there's not really a tool that does what we would like in terms of our delivery. [Method] So we're going to build one and that's what we've been doing.

Matt Genovese: And it's, it's meant for us to use, but also it's meant for other people to use too. So to answer your original question, yes, we're just starting to, bring on clients to go and use it in a limited capacity right now, as we're doing evaluation. But it was really meant to solve the problem of Capturing and hosting requirements.

Ryan Purvis: Yeah, I mean, you sold me on it in a lot of ways, because that's what you talked about. Exactly what I built into notion. And the reason why I use notion is because notion has a concept of blocks and blocks can self reference. And I mean, it's not a graph database, but it is the same concept. You can self reference it's a very complicated structure.

Ryan Purvis: I mean, I don't want to show you what it looks like in notion and the problem with notion is it doesn't It doesn't visualize very well. And all the things you've talked about, you know, the breaking down of things into smaller pieces, and they've been able to bring it back up. And I mean, if you could get it to the point [00:26:00] that that item that you've got in your tool is connected to the check in or the pull request in

[source cotrol]

Ryan Purvis: Then you can trace lineage and all that kind of stuff.

Matt Genovese: That's right.

Matt Genovese: So

Ryan Purvis: yeah, I mean, I'd love to see where you guys are going with it, because I think that's especially when we start going down this route of generative stuff. Generative, generative code, generative user stories. I mean, you know, all the stuff that I do in Notion, the reason why I like it is I can actually write a prompt to generate the user story for me.

Ryan Purvis: It's not perfect. Don't get me wrong. You know, I'm not saying it solves that problem, but at least I don't have to go and write a user story every time from scratch. So I'm now reviewing user story. I can fix it and then regenerate the acceptance criteria. And it just kind of gives you you get that speed, but now you need to tie that back to other things because otherwise it kind of sprawls and you want to avoid sprawl.

Matt Genovese: That's exactly right. Well, we've. I was smiling, Ryan, because that's exactly the realization I had about a year or so ago and in fact, in October 2022, we released this little application called UserStoryGenerator. ai. And it was doing [00:27:00] exactly that we were running at the time. There wasn't even chat GPT.

Matt Genovese: It was on GPT three. I had downloaded the year, year or so prior. I downloaded GPT two, which at the time you could still download and, compile on your, I had a little Linux box here and I was running it on there to do some generative AI, but only when GPT three came out and had the AI, the API that I start really seeing, Hey, what can this do for enabling product management and product development teams to be more efficient.

Matt Genovese: And with that user story generator, which is a free tool, we learned a lot about how people use it. We don't care about the ideas they put in because the idea was to take it from a, you know, some product idea or description to user stories at the end of it. But we want to understand the process and, you know, what it could do.

Matt Genovese: And what we found was that, yes, it could help you write user stories, but even better, there are two things. First of all, it could help you get past the blank sheet of paper, could help you get past the point where you're like, I don't know what to write, right? You're just having some writer's block and to get you to a place where you could go into edit mode, perhaps more than, just [00:28:00] creation mode, which tends to be faster for a lot of people.

Matt Genovese: And secondly it did help with brainstorming, thinking through what other areas of this application that I want to build or that I'm working on am I not thinking about? What should I be thinking about? And it, the AI, the language models did a really good job. I'm starting to help you think about especially if you're thinking about roles, right?

Matt Genovese: So many people think about, well, here's the, end customer. And they have 2 or 3 roles that they're going to be in. And then there's other administrative roles too. Well, the administration is also very important. In fact, when we. Work on scoping with our clients and thinking through any feature that's required one of the immediate next questions is, well, how are we going to administrate this feature?

Matt Genovese: What do we need to allow for? You know, what variability do we need to allow our customization so that you don't need to have development go and help you do something later on when you learn something new where customers require X, Y, and Z or customer administration, right? When they have to manage roles and permissions and.

Matt Genovese: Data access and policies and things like that thinking [00:29:00] through that and having this kind of virtual assistant, this virtual product management assistant to help you think through that is very useful because product management in the end of the day is a pretty lonely job. And if you can benefit from having this sidekick.

Matt Genovese: To help you think about what you is in your blind spot. It was really useful and that's what we built into Sinfonia actually was this ability to have it help you brainstorm and also help you think about how to break down some of those problems in that feature map where you start from, you know, either a high level or at a mid level and say, okay, I think I've got this organized the way I want.

Matt Genovese: I want to have it start helping me break down. Into possible tasks that need to be done, right? And it's it's not meant to replace product managers by any stretch. It's to accelerate them and again help them identify blind spots and work more quickly and efficiently and certainly not feel alone in the process.

Matt Genovese: Because like I said, having been a product management person myself, you can certainly feel like it's all on you, right?

Ryan Purvis: Yeah, yeah, you can be very easily overwhelmed. I'm finding that now at the moment because it's a new space for me. So I'm finding the frame, I [00:30:00] don't have that frame of reference when people say things.

Ryan Purvis: So, you know, often you, are kind of going, they said this thing. What the hell does that acronym mean? Or what does that word mean? Like a remittance versus a transfer versus whatever. And, you know, it's, good because you, it forces you to learn. and that's a positive thing, but also you're slowing people down because you've got to and the way you've approached it with what you do with the product we've done something similar with another product of mine Valuu with OKRs, so OKRs, if you say to someone, what's your objective, they get, sometimes they get a little bit concerned that they haven't said the right objective or they haven't said it in the right way, and part of that process, it just lets you to say, look, you know, needs to have a number, needs to have A date. And we need to know the outcome is so let's work out to what your outcomes are. And then that sort of starts a conversation. That's the consultative approach. And I've been toying with using a conversational AI to do that. And I'm wondering, part of me says, Yeah, you could do that for some people.

Ryan Purvis: And I'd be happy with that. But some people like the conversation. They like to have the brainstorming. They like to see you struggle a little bit. As well. [00:31:00] Sure. Which I thought was very interesting feedback from somebody said, well, actually I don't, I, I know I could go to Chatt DP and do this and it'll probably be quick, but then I don't, then it's too easy.

Ryan Purvis: I wanna see somebody else struggle with what I'm thinking about at the end. That's actually got an interesting.

Matt Genovese: Probably the person who's doing, it's gonna be using chat, GPT anyway. These days it's useful as a tool to help broaden your perspective. I think the challenge is it's so new right now, like many types of brand new technologies to the market.

Matt Genovese: There's a question of how far does this go? and there's certainly a desire for certain types of folks to say, well, can I just remove my brain and put this in and let it do all the work for me? And I, I can just sit on a, you know, sit on a beach and just press the enter button a few times and things magically happen on my behalf.

Matt Genovese: And I don't think that a AI is certainly an easy button for many things that we've never seen before. But it is not. In any way of permission to just extract yourself entirely from the situation, for example, [00:32:00] user story generator and symphony that I was just telling you about, right? It can think up features and user stories for you.

Matt Genovese: Great, but you can't, be sure that that's actually solving any of the problems for your customers is giving you points to investigate further and again to look for areas that perhaps you hadn't thought of, but you still need to do the investigation yourself as a human to validate that these issues are actually ones worth pursuing.

Ryan Purvis: Yeah, you're 100 percent right. And I mean, that's even with the notion stuff that I'm doing. You know, you still got to spend the time looking through it and go, yep, that looks right. Okay. that's probably, you know, it hasn't got this at all. Like it's completely missed the boat on this one.

Ryan Purvis: and that's fine. But you still, you know, as I said, you're not spending a lot of time trying to regenerate. Well, you're not trying to write all the user story yourself. You're now just checking and tweaking. And I do find, and actually someone taught me the skill last week, you can now create your own chat GDP which is private.

Ryan Purvis: If you're paying for it, you have to pay for it, obviously, but, but now you can privatize it. And you know, I'm now loading up stuff in there to teach it all our stuff to see [00:33:00] if that would work. And if that works, then I think, you know, I'm a lot more comfortable to let it go and generate. These stories, because now I know it knows about, you know, in this case, Finxone and the other one will be Valuu to do the right things.

Matt Genovese: I think we're going to find ourselves in some areas playing the role of oversight, you know, looking at what it has generated and saying, yes, that's correct. Or no, I need to tweak that but That tends to be faster if you do it in a structured way that tends to be faster than having to write it all from scratch.

Matt Genovese: Yeah, we've been very careful with that. And again, in the tool that we built you know, it can generate a feature map for you of level 1, We call it basically the top level. You know, area or the talkable activity and then breaking it down into feature areas and then breaking them down into individual features.

Matt Genovese: We could build all that from scratch and just throw it all on the screen and say, here, here you go. Here's your scope, but that is really not solving the problem for the product manager because they have to go and absorb it all. Right. And maybe maybe some of that is [00:34:00] incorrect. So you have to put in some of these points of oversight and say, look, this is what we produced.

Matt Genovese: Does this make sense? Let's go edit and change what move things around. And then once you're agreed that that is correct. Now we go and break it down again. And now you have a chance to review further and walk them through a process. So I don't think everything's going to become a chat prompt. I think you still have value and the UX.

Matt Genovese: I think going forward is going to be if there is a built into the application, which seems like today, it's going to be hard, you know, to imagine ones that won't you still have to have the UX there to assist the user going through the process of accomplishing what they need to do. And you pull in AI at the right points.

Matt Genovese: Sometimes it may not be. I mean, not everything's going to be a chat. Right. I think there are some areas that will be conversational, but not every not everything by a stretch and having the A. I. I'm having the U. X. help you to walk through the process of your job to be done.

Matt Genovese: You're leveraging A. I. As a tool, but A. I. Is not becoming the end. You know, the end, it's the means to the end. Yeah, it's [00:35:00] assisting you through that process.

Ryan Purvis: Yeah, I mean, I had this conversation with some people on Saturday night. I was, because I'd learned the skill now at ChatGDP, I was generating my kids comic book.

Ryan Purvis: And I was showing them, and they were, obviously, it was a lot of fun. And they were saying, like, this AI stuff's beyond me, and I said, well, to be honest with you, you need to get your head into some of this stuff, because, you know, the future of your jobs will change, and if you're not savvy, and I'm not saying you have to be an AI expert, but if you don't know how to go, if you don't know which ChatGDP is, you're already behind.

Ryan Purvis: And yeah, that's the truth. You don't have to, you don't have to go learn long, large language models. You don't have to, you know, but you need to be comfortable with it. When you go into a conversation, you know what people are talking about, because that's the minimum now for a lot of people

Ryan Purvis: I

Matt Genovese: think we're finding the extents of what's possible. And the more that you go in and play around, you figure out, Oh, it's good at this. And it's not good at that. And if you're, on a product team, that does help you to know where it could be useful and where it certainly might not be.

Matt Genovese: Right. And that's the value of doing exactly what you said.

Ryan Purvis: Yeah, and I think there is a level of exploring it as part of day to [00:36:00] day stuff and then realizing that you've got to put in your own guide rails. So, for example, you know, not every customer wants it to be incorporated, so you need to be able to turn it off.

Ryan Purvis: You know, you cannot build your whole product around using an AI because some people like a bank may not want to use it because they don't want to put their data into it. So there's those sorts of things, but I think that's just natural evolution. Matt, unfortunately, I need to end it off here because I've got to go fetch the kids from nursery.

Ryan Purvis: No problem. It's that time of the day. That's a good reason. Yeah. how best do you want me to get hold of you?

Matt Genovese: Oh, sure. probably be the easiest to go to our website planorama. design. Yeah. Slash podcast. And so yeah, the, the domain is actually.design. So it's Plan Panorama with a set of panorama.

Matt Genovese: It's a pl so plan like panorama design slash podcast. And that has links to, find me on LinkedIn. And, and even if you wanna set up a call. and talk through certain things. We're happy to do that as well. So it's the easiest way to get hold of me.

Ryan Purvis: Great. And it's been great chatting with you.

Ryan Purvis: I've really enjoyed it. And I will definitely get in contact with you in following up.

Matt Genovese: That sounds wonderful. I'm [00:37:00] looking forward to it. I had a really great time. It's the time went by really quick. Yeah, it did. Always a good sign. Thank you, Ryan. Super Matt. All the best. Cheers. Thank you. Bye. Take care.

Matt Genovese: Goodbye.

Ryan Purvis: Thank you for listening to today's episode. Heather Beckner is our producer editor. Thank you, Heather. For your hard work on this episode, please subscribe to the series and rate us on iTunes at the Google Play Store.

Ryan Purvis: Follow us on Twitter at the Dww Podcast. The show notes and transcripts will be available on the website, www.digital workspace works. Please also visit our website, www.digital workspace works. And lastly, if you found this episode useful, please share with your friends or colleagues.