[0:02] Hi, welcome to Prototype to Production by Razoyo. Over the next few minutes, we're going to talk about how to take a messy codebase and turn it into a scalable application. And I'm going to give you some specific things that you can take with you and implement today. If you are responsible for a digital product of any kind and have ever said any one of these things, we don't remember how our system is built all the way down to the system feeling outdated, then you're in the right place. And my goal is to get you some information that you can use right away. So, let's talk about the cycle before you figure out like what it is you need to do with your product. The first thing you need to understand is where you are in that build cycle. And pretty much all systems go through this life cycle from planning all the way to building, evolving, maintaining, and then at some point you're going to have to rebuild and recycle back to that planning stage to a certain extent. And if planning is done really well, you can improve the ROI or the return on your development efforts.

[1:14] And what are the stages to the steps to success? The first is pre-planning. And this is the one that we find is most often skipped over and definitely should not be skipped over in any sense. But then also you have to understand and define your value delivery mechanism. You have to write out what your user stories are in a way that developers can understand and work efficiently. And then you're going to come up with requirements and a project plan from there. So let's talk about the pre-planning phase. And the pre-planning phase is mostly about defining what your objectives are. Not only your objectives, but the users's objectives, the admin's objectives, the business objectives. You what should go right and what measurable success criteria for our personas, whether they're admins, end users, or even non-users of the system.

[2:10] It for us to declare success. And the reason that you need to create this context is that it's going to help your developers understand the business environment that they're working in and make good decisions. And the less guesswork that developers have to do, the more quickly you're going to be able to develop and the less you're going to spend on their time. It also keeps you focused on what is important and it will help you filter out new ideas that come along as to whether they're good or bad ideas and you should act on them and that's going to accelerate your process as well. So write up your objectives, personas and success criteria is the first step.

[2:54] The second step is defining that value delivery mechanism. And what is a value delivery mechanism? Well, simply stated, this is just a written expression of your strategy to deliver the results that you and your users require. And basically what we're talking about here is mapping inputs to outputs. So that's the primary thing that we're focusing on here is how do we get the right inputs to the right outputs? And think of your value delivery mechanism for either your web app or your SaaS product. As a factory. Your data and your data sources, those are your raw materials and the user experiences that you're going to create on a web application or on a SaaS product, those are the output.

[3:45] Those are the tidy packages that are delivered to your customers. So, how do you get the inputs to measure up to the outputs? When you define this, mapping those inputs to the outputs, that is the definition of your delivery mechanism. Let's talk about user stories. Probably learned to write user stories in the past, but we're going to talk about writing them in a slightly different way and you'll see some familiar things with this take on a user story. But I'm going to add two important things and one other thing in the middle that will affect the effectiveness and the ability of your developers to give the correct results. If you've ever had a developer deliver something you thought, "Wow, this is way off." It might be because the user story just didn't give them enough to go on and they will make assumptions. Many developers are a little shy. You know, they may not ask the question. So getting these user stories right is critical. So you want to give them an initial state. What was happening? What page am I on? What am I doing? What is being displayed on the page at the time that this user story starts or this process starts? And then what is it again at the end? What has changed from my initial state to my end state? And these can be bullet points of things like oh I have this in this particular list or this is on this certain side of the page or this particular page is being displayed and then the user takes an action which you're probably used to writing. But the one thing that we're going to add that you're probably not used to thinking about is based on what data source. So the user's going to take an action, but then if you define the data source, the developer does not have to guess. And I would say, you know, maybe two or three times out of 10 when they get it wrong, it's because they're not using the right data. And also, this is going to help them create the data structures, which are the critical piece, the critical foundational piece of architecture for your system architect.

[5:56] You're going to come up with user stories and you're going to throw these into four buckets. So one is items that are critical items that are important what is polish for the website and then what was I thinking and you're going to do different things with these. The critical things are going to become part of your minimum viable product. These are the things that you can't do without the important things. These are either going to be the things that you will do with your system if you have time or fast follow on. Polish is stuff that like, you know, would be nice to have. And what was I thinking are things that are not maybe just bad ideas, but potentially just kind of a waste of time. And you're this requirements documentation is going to help you filter through new ideas as they come into play, but it's going to help you organize yourself. So, you're going to take these user stories and you're going to put them into groupings. And these groupings are not going to necessarily be in the functional components of the application or the site that you're developing, but they are going to share views andor data, most likely both. And then you're going to have the same personas using these. And once you can group these together, then the names will kind of come out. You know you're going to spend some time on it but they'll be easy to easy to write. Then you're going to catalog the data structures that are required to make these user stories work. So not only the data structures but where those data are coming from and then you're going to work with the dev to architect the solution. You're going to define what technical components, external sources of information or you know am I using an AI or an LLM you know something in here like what are the components that are going to be required to make the user stories come to life and then finally work with the developer to figure out the level of effort which you may or may not be used to doing. And now you're going to flow into the project plan. So the project plan is going to have not only a list of your user stories and your business requirements document, which is essentially what that list of user stories is, but it's also going to have the team. And if you go into a project and you haven't defined the team, and I would say preferably by name, you don't have a project plan in place. You're going to have this backlog of user stories that's going to be ready to go and they're going to be prioritized by the groupings of the user stories.

[8:28] You're going to have a calendar and the calendar is more about when you expect things to happen in what order, but it's going to be relatively loose because unless you've gone through the level of effort to plan out every moment of every day and you're not willing to make changes on your on your plans, then you know you're going to calendar things out so that they're approximate. You're going to create a schedule and this just means what time are standups, who's attending them, who's attending the, you know, the reviews, the sprint planning meetings, etc. What those milestones are and we'll talk about that next. And then kind of what reports are because if I can't get reports out of the system, I'm not really getting what I want. So, what is a milestone? Well, this is the last thing that I'm going to cover. And the milestone is going to be a group of user stories that makes a notable improvement, one that you can notice and, you know, touch. And it's got an MVP attached to it, a minimum viable product. So, we're not going to build out everything in our milestone. Our milestone is going to be what's the minimum that we can test. And what is going to be inexpensive to rework. So if I build out all the bells and whistles and I have to update nine or 10 different features then I've gone too far and that's going to be expensive to re rework. And finally we're going to order these in developer logic not in project manager logic. And once we've done that now we've got a plan in our hands that is going to be affordable.

[10:15] It's going to be quicker to implement and we're going to be able to spend less time focusing on miscommunications with developers and more time on really just running and getting things right and spending time in the important details of the project. Thanks for listening. I would encourage you if you'd like to hear more about this and understand this framework and some of these details a little bit more, please join us in our webinar. You can sign up on the page below. And thanks again.