Product Management Roundtable: Product Management and UX – Agile Sprints
Wonderment Apps is proud to present The Product Management Roundtable, our insight series that shares insights into the product development and product management process. In this episode we will be looking at how to create effective agile sprint structures for the Product Development and Design/ / UX processes. This video should offer some useful perspective on areas within pre-technical project management that might help your organization optimize its overall development process – no matter if you are a a startup or enterprise tech organization.
We strongly believe that proper product management, excellent product development, and thoughtful UX dramatically improve the quality of every technical piece. Please make sure to watch the video to learn more and please share comments with us.
————————————–
PRODUCT ROUNDTABLE TRANSCRIPT
The Value of Product Management and Design Agile Sprints
[00:00:14.900] – Ryan Williams
Hi, everybody, I’m Ryan from Wonderment Apps. I am one of the partners here. I also have a very extensive product management and product development background. Today we are sitting with the Wonderment apps, or at least part of the Wonderment apps, product development and product management team. We’ll introduce in just a minute. This team has worked across a lot of different projects and both their career and here at the company, and they wanted to share some insights around how they do product development, product management.
We’re going to be doing a series. This is the first in the series where we’re going to look at different parts of the product management, product development process and hopefully give you some useful perspective on areas that might help your organization. Or if you’re just starting a startup or you’re building a tech organization, you’re thinking about some of these pieces. We will look at a combination in the series of product management, design and product, anything that has to do with product tech handoff.
[00:01:18.950] – Ryan Williams
Awesome. Are you guys excited? Give me a call. So I want to go around and introduce the team. You guys go on mute. If you’re not talking and then then we’ll just kind of go around and introduce you to everybody. So we’ll start with Alexandra. Go and introduce yourself and maybe tell us a little bit about what you’ve done in the past that led you to wonder and then some of the things that you’ve worked on here in the company.
[00:01:43.970] – Alexandra Adelman
Absolutely. My name is Alexandra Adelman. I worked for years in the e-commerce industry. Everything from Web to apps, international and domestic. And that experience and that broad applicability of the broad base of products for which for which I was doing ongoing work. That’s part of what led me to Wonderment. Since joining the Wonderment team, I have worked with startup companies. I’ve worked with enterprise companies, I’ve worked sassed products, lifestyle products. And it’s just been it’s been an evolving journey. And I continue to learn a lot.
[00:02:37.140] – Ryan Williams
Awesome. Thank you. All right, Joe. Can you Introduce yourself.
[00:02:41.600] – Joe Gillette
Sure. Yeah. Hi, I’m Joe. My history is mostly in design and UX design. I got my start in the industry working mostly in ad ops and ad networks. I actually did develop a lot of new products for some of the biggest ad networks in the entertainment vertical. So I’ve got a lot of history in entertainment as well as gaming.
[00:03:07.850] – Joe Gillette
I’ve also worked in SAS products. I worked in lifestyle products, health care, financial, a little bit of everything. And so I came to Wonderment Apps about four years ago with a pretty strong background in design and UX and then got integrated to the product team and started taking on more and more responsibility there. And then I’ve had the opportunity to just kind of grow with this team and with some mentorship from some great experts in the industry and have just kind of continued develop that and develop my product skills and strengths in different areas.
[00:03:46.070] – Joe Gillette
And I’ve gotten a lot more into now sort of product management and some of those skill sets and just excited to kind of keep pushing keep developing that.
[00:04:01.060] – Ryan Williams
Thank you. Amy tell us a little bit about yourself.
[00:04:05.850] – Amy Halvorsen
Hey, I’m Amy. I have a background in UX and product design, predominantly UX. I’ve worked from startups to enterprise companies predominately on internal applications. Those are my background comes from and I’m learning with Wonderment on product management. That’s my newest task. And I really enjoy solving complex problems.
[00:04:36.000] – Ryan Williams
Awesome thanks. I’m Ryan. I’ve been working on product for 20 years or so. I worked on a variety of different things from web to mobile. I have a lot of expertise in ad tech, a lot of expertise in media and entertainment. A lot of expertise in SAS products. And we started the company on the belief that blending really good product with really good tech would lead to really well constructed digital products, which has generally been the case.
[00:05:08.080] – Ryan Williams
And it’s great. And we strongly believe that good product management, good product development, thoughtful UX really dramatically improves the quality of every technical piece that’s out there. And I’ve worked with companies as big as New York Times and Apple and as tiny as the smallest startup you can imagine. So I’m kind of experienced in a lot of different things and excited to share some of that with you. All right, so today’s roundtable topic is going to be around the product sprints structure.
[00:05:42.640] – Ryan Williams
We’re very used to in the technical industry having text sprints that we work on. So these might be two weeks sprints or four weeks sprints, but they’re really designed so that tech teams can get in and execute with efficiency and then return deliverables within a sprint period. This is coming out of an agile sprint process and it can be really customized to work with any organization type. A lot of times product is just kind of slotted into the tech sprint structure. But one of the things that we work on with product teams out there is actually developing a thoughtful product and designed sprint that goes in tandem or in connection with a tech sprint.
[00:06:27.040] – Ryan Williams
So they actually work a little bit separate for one another, but they work in relationship to one another. So today we’re going to talk a little bit about that particular subject area and what we won’t do. So I’m going to ask the team questions and kind of get some feedback. And I’ll chime in with my own thoughts around that as well. We do have a process that we use here and we tend to bring it into the organization and guide people on it. But we know that it is pretty custom in general.
[00:07:03.400] – Ryan Williams
So I want to just start with this. What is the value of having a product and design sprint? And why would that need to be separate from a tech sprint? I’ll start with Joe.
[00:07:21.430] – Joe Gillette
Yes. So there’s I’ll answer the second part first. So. Why it needs to be separate from a text sprint is that our process, like the process of design and product is different in every way from the technical development process, from engineering and all of that sort of stuff. And the deliverables that we produce come from a little more of an open-ended kind of creative process in many ways and less of a sort of binary engineering, problem solving sort of process. Now, by the time you get to development, it’s very much here. Is the task here or the requirements make it work? And in product, we are the ones to figure out what are the tasks, what are what are the needs?
[00:08:15.750] – Joe Gillette
What are the requirements. And that process. It is not always 100 percent linear. So. The methodology for four our kind of work is just so different from technical development. And then the reason. The reason that it’s good to keep them in separate sprints is because having a clear delineation between those work streams and knowing that when a tech sprint starts, all of those requirements are in place. Those product requirements are in place.
[00:08:53.310] – Joe Gillette
Some technical specifications are in place, wireframes, flows, things like that. We come to the table with those ready at the beginning of a tech sprint because we’ve done that planning in our product sprint. And a lot of times in a traditional sort of sprint structure where we’re just kind of horned in with the development stream, it’s just like expected that we show up and all of those requirements are defined and we have all the answers. And it’s not so much always accounted for that we’ve got to do that work. We’ve got to put in the time on that.
[00:09:24.160] – Joe Gillette
So generally, we kind of look at it like, you know, if it takes two weeks to build it, it’s going to take us two weeks to gather those requirements and define those specs as well. So it makes a lot of sense for us to create those two work streams.
[00:09:48.640] – Ryan Williams
Alexander, I know you’ve put together a number of these over the course of time, when you think about the two weeks that Joe’s talking about and kind of what goes on in those two weeks. What are what are some of the things that you generally include in the two weeks, as part of that sprint process?
[00:10:07.380] – Alexandra Adelman
Yeah, there are. There’s always a selection of work, selection of work that’s going to be accomplished over the next two weeks set, that is going to end up in the hands of development. There are regular check ins between the product team and key stakeholders, whether it’s the business team, its external users, internal users, even the development team itself, just to ensure that, as Joe said, all of the requirements being gathered and the tasks being established that they are on the right track for the product and for the people who are going to be using it. And for that and for business needs. But then also, it’s always really important to ensure that the tech team is brought in and that they have the insight and a say in the process early on. So that way, product doesn’t go too far down one path. That makes things more difficult or impossible for tech to accomplish once that once the task is in their hands.
[00:11:24.190] – Ryan Williams
Yeah, that really reminds me of the need for good stakeholder feedback, right? And I think that’s one of the differences in the product sprint process as far as the tech sprint process, his product is really trying to pull insight out of all of the different people to collect it and actually put it into an executable form versus tech being an execution mode. So that kind of underlying quality of the sprint itself is a little bit different in that way.
[00:11:55.570] – Ryan Williams
So stakeholder feedback and getting really good communication flow going so that you can feed that back in and create the creative elements, seem like it’s one of the more important parts. Right?
[00:12:10.380] – Alexandra Adelman
Absolutely, and critically thinking about different use cases and scenarios and edge cases that can happen and how. And what’s the and how stakeholders will have input in those flows so that as many of the questions that could come up around something have already been answered by the product before it even gets to engineering.
[00:12:31.410] – Ryan Williams
Yeah. So, Amy, here’s a question for you. What are some of the things that like? What are some examples of see things that you kind of want to prethink for tech before we get into them and ultimately probably want to visualize?
[00:12:53.060] – Amy Halvorsen
Yes, sure. Just thinking on recent projects. You know, where things go and how they’re placed and right now we’re working on a grid system and where is it, how things are formatted and.
[00:13:13.040] – Amy Halvorsen
What elements do what on a page, we have to basically leave directions for dev on how to do that. So we do that by writing annotations after designs have been done and approved. So a lot of my work recently, I’ve done a lot of calculations. So I have to leave directions on. How certain features, parts of features get calculated. So it helps them in the backend say, oh, you know, this is calculated by X display. This if this.
[00:13:48.960] – Amy Halvorsen
So there’s a lot of rules you have to write in the background. That you should leave to Dev. That’s just one example of the things I need to think about in my current project.
[00:14:02.410] – Ryan Williams
One of the things that comes up around that and in my career, I’ve been in a couple different types of product organizations. Some are really kind of like business driven organizations, meaning that like a lot of the decision making comes out of the business side and some are really engineering driven organizations where the engineers are kind of the main drivers of it.
[00:14:22.000] – Ryan Williams
And I notice that the stakeholder balance shifts between those two things. So when you say we need to leave guidance for the developers. Right? One thing I’ve noticed is that in some organizations that guidance needs to be super specific down to like it needs to be calculated exactly like this, because I think probably in your case, there’s a specific business logic that affects other systems outside. And the developers aren’t necessarily engineering for that particular piece.
[00:14:53.590] – Ryan Williams
But you also don’t want to take it as a product person. You’re trying not to take away from the engineering itself from the developer. Right. So you’re trying to guide them towards engineering the solution. And so, like, how you do those kinds of annotations and feedback from a developer, that is that is a part of the sprint process. Right?
[00:15:29.240] – Ryan Williams
Joe, what are some of the ways that you within the sprint process would look to do that communication and kind of prepare that communication for the developers?
[00:15:43.940] – Joe Gillette
Yeah, that’s a great question. So, you know, an important distinction is that, you know, that the language of the stakeholders, the language of the business, does not directly translate to engineers. If you hand them a stack of documents, no matter how detailed those documents are, you’re not going to get back what you need and what you want. Right. So what we do know, and this is from our experience of working with development teams of all different types and all different sizes, whether that’s our internal team or the client’s team or whatever the case may be, you know, we’ve kind of created this system and really honed this system in such a way that we really know how to speak their language.
[00:16:29.290] – Joe Gillette
And one thing that we’ve learned is that, like visuals go a really long way. So, you know, delivering really, really clearly defined user flows and user stories is super helpful, delivering like Amy was saying, annotated wireframes. But, you know, more than just annotations, we have a really sophisticated system for taking those wireframes and detailing the flows and all the possible scenarios and edge cases like Alexander was talking about. And what’s the logic that drives some of those features and what are the business needs? What are the different cases that we need to account for?
[00:17:11.240] – Joe Gillette
All of that, we start we start preparing these highly visual packages of assets that include the flows, the wireframes, the comps, as well as all the assisting documentation, the requirements documentation. Feature inventories. All this sort of stuff like we try to distill the information as much as possible. So, you know, we’ve got all of the supporting documentation if we need it, but we try to distill it into this like a really visual format. And then we deliver it to our developers or to the client’s development team in a package and we package that up, whether it’s in whimsical or slideshow.
[00:17:47.870] – Joe Gillette
You know, we just make sure that all of the deliverables are accounted for. We’ve got links to all of the important documents, all the assets that the development team might need. And we put that all together in one central place, a repository, so to speak. And we pass that off in one package. And then also that’s sort of oftentimes like a living document. Right. So, like, as requirements evolve, we just keep updating those same documents and the links stay the same. You know, you can find it. You can find the latest answers there at any given time.
[00:18:24.840] – Ryan Williams
Yeah. Alexandra. As you’re moving through very fast sprint processes, I think probably on average, these run about two weeks, right? You have about two weeks to prepare these things for ongoing development. And in that, like, ongoing development cycle, you have to be quick in terms of the assets that you’re going to ultimately create and that requires really good decision making.
[00:19:01.710] – Alexandra Adelman
And I know in the process that we work on, we generally make sure that everyone’s involved in kind of the very first meeting so that the decision making of what to work on is actually done. What can you say a little bit about how that meeting would go with, like some of the key stakeholders so that everyone agrees on kind of the next steps in the roadmap? Yeah, I think at that point, it’s really important to have key voices from the business team as well as the technical team in the room, because business will be able to provide a voice towards what’s needed? What’s the next step? What’s the direction that the product needs to go in? And then tech can have a voice towards what? What can we get accomplish in the amount of time that we’ve been allocated? So it’s as Joe mentioned, oftentimes these two groups of people don’t speak the same language. So it’s important for product to sit in between them and say and listen to what do we need for the business, what are our users’ needs? And then what can we accomplish in the amount of time that we have? And how do we choose? What’s the highest priority? What’s going to have the most impact and what is accomplishable?
[00:20:29.340] – Ryan Williams
Yeah, one thing I’ve found and tell me if you’re feeling I’m wrong. I like to have the tech team in tech team leadership in that first meeting because a lot of times they can hear, here’s a good example: Business team and even sometimes product is like, yeah, that’s an easy thing to do.
[00:20:50.820] – Ryan Williams
We can totally knock that out. This should take like one sprint. Right? And then and then the tech team hears that they’re like, do you guys have any idea how complex what you’re asking? And really no one does. So how do the tech leadership there to actually give insight into our often an unrealistic expectation is helpful, right?
[00:21:15.230] – Alexandra Adelman
Yeah. And you’re absolutely right. And sometimes it can even go in the opposite direction where you’re like where business and product. They’re going back and forth. Oh we can do this, this, this, this. It’s complicated. It sounds this sounds tricky. And then tech comes and it’s like, well, we made one slight tweak to how you want to accomplish this. You know, if we do it this way, we can do that in two days.
[00:21:37.500] – Ryan Williams
Cool. Yeah. Does anybody else want to speak on that?
[00:21:45.770] – Amy Halvorsen
I do real quick. Yeah, I know that we with one of my clients, we had a whole day that was dedicated to working on priorities and questions and upcoming problems are things that we possibly would foresee in the future. And we would spend a whole day. I mean, sometimes half a day just working through potential problems that would come up for Dev and reworking solutions with product that could make things more efficient.
[00:22:18.860] – Alexandra Adelman
I want to add that. I think it’s great to give tech leads like. A sense of ownership in the project also, right, in the sense that, you know, that they’re there. They’re part of the decision-making team. They’re part of what’s, you know, what’s guiding the product. And they have a say in what’s going to come to life, because very often, you know, business team, internal teams, user groups, these are very loud voices the way the product is going to work. And allowing the dev team to have to have their say also is I think that’s part of what makes a really robust product.
[00:23:14.810] – Ryan Williams
Joe, so like so coming out of that meeting, right? We end up with a lot of like kind of direction and stuff like that. What’s a in the history that you’ve been working what’s a good way to like at that point break it into deliverables that the product would execute on within the sprint? Like how do we look at those things and break them up a little bit?
[00:23:35.020] – Joe Gillette
Yeah, that’s a great question. So, once we’ve met with the client, we’ve met with engineering, we have a good sense of where we’re trying to go in the sprint and what we need to accomplish. We’ll typically break that out into tasks. What are the action items? What are the steps we need to take to get to that deliverable?
[00:23:53.760] – Joe Gillette
So, you know, in our case in Wonderment we typically work in JIRA. Some of our clients use other softwares. But you know, we’ll create an epic. If there needs to be an epic, we’ll create all the tasks and subtasks that will lead us to the goals that we’re trying to accomplish. And then a lot of times on this team, each of us, we’re used to like owning a whole lot of a whole lot of that process on our own.
[00:24:18.330] – Joe Gillette
We work in pretty small and nimble teams. But also, often you’ve got a supporting designer. You’ve got maybe some additional product support. You’ve got different people on your team that are responsible for different tasks or even in some cases business, marketing, different departments have different pieces that need to click into place in time for you to get that deliverable over to tech. And so just getting a project management structure in place and making sure everybody knows what they need to do and when they need to get it done, setting dates. Truthfully.
[00:24:55.100] – Ryan Williams
I know. Like, this is painful for some product managers here that I’m not a project manager because I’m a product manager. But it sounds like they’re like I know we find value in some level of capability of managing project, especially in complex projects that have a lot of graphic or a lot of like flow deliverables. Right?
[00:25:18.180] – Joe Gillette
Yeah, absolutely. Yes, it’s key to what we do.
[00:25:31.210] – Ryan Williams
One question is. Amy, I’ll ask you this one. How useful is flow development to lead to the figuring out what you’ve got to deliver out of, like, what actually needs to be delivered on a visual aspect?
[00:25:47.340] – Amy Halvorsen
Are you talking about, like, building flowcharts and whimsical?
[00:25:50.640] – Ryan Williams
Yeah, like it’s easy, it’s easy sometimes to just go straight to the screens and be like we’re just going to do this thing. But, like, you can’t actually see the conversion flow. I have experience, like, you pass off things that are incomplete to the dev team and it creates a lot of back and forth on the dev cycle itself.
[00:26:09.440] – Amy Halvorsen
Yeah, so a few things on that. So, I learned my lesson. I think the hard way and one of my projects where I started, I was really excited and I built all these screens and then after maybe like fifteen screens I made, I took a step back and was like, this doesn’t work. And I had to go back to Dev and say, how, you know, how are you piecing this all together right now? And that’s when I was like, OK, let’s stop, let’s have a meeting, let’s work on this together. And we’ve put together a flow of how everything should really be working together. Which was incredibly helpful. Well, first of all, to the whole team, but also to have that as a piece of a handoff to Dev that says if this, then this.
[00:26:54.910] – Amy Halvorsen
So, you know, there’s multiple routes or paths that can be taken in within a product. And it’s critical as a handoff to Dev to say, this piece goes here, this goes here. This goes here and I have learned now that these things need to go up front. They need to be done and approved and worked on as a team in order to build something that can be added on to and is correct. And you get all the problems out ahead of time.
[00:27:34.010] – Ryan Williams
I want to talk to Alexandra about this, too. I consider Alexandra one of our like Flo Masters here in the organization. She’s got like massive expertise in how to build really helpful flows. One thing that comes up along the lines of what Amy just said, too, is that those flows are used not just by dev, but they’re also used in the QA process as well. So, like so we’re actually giving insight into how things need to be tested at the end as well. Can you talk a little bit about that?
[00:28:14.600] – Alexandra Adelman
Yeah. I want to reiterate something that Amy said, flows are everything, flows are absolutely everything. They’re useful upfront tools to communicate that again, to communicate with your stakeholders, that you yourself are thinking about things correctly and that you’re taking the user down the path that they want, that they want the users to go down or that the users want to go down. But then, yes, flows. Because QA is expected to test the user journey and the user experience without necessarily having the closeness and the insight to the action to the user’s journey and experience that product does. These flows in these Step-By-Step sequences of like user does this here is how the system responds user does this. Here’s how the system responds. That’s a really insightful way for QA to be able to just do that first path of checking whether or not what has been implemented is meeting the expectations that product is set forward. And it’s like you’ve already done this work of communicating to, you’re not creating New QA steps. You came QA processes. You’re just like translating what’s already been done.
[00:29:36.350] – Ryan Williams
I look at it like I look at it like product like in all of the relationships within the cycle. So, if I look at all the stakeholders, product really represents the customer at the end of day. So, we’re really primarily thinking about is the customer going to have a really good journey or is a user are going to have a really good journey through these screens convert the way that we want to do and like probably our biggest ally in that and making sure that that’s the case is Q&A.
[00:30:05.680] – Ryan Williams
They also represent the user. They represent the actual user experience before it gets to the user. So, giving them the tools upfront and product. Like, if you’re just creating a juror ticket for like, hey, I want to do this small tweak on this thing that you’re actually writing a test case within that juror ticket as well. So, it’s so it’s like that you’re the people who are going to help you out down the road once the thing’s done and make sure that kind of hit the mark.
[00:30:31.390] – Ryan Williams
You want to give as much insight as possible and end the devs. If you do that for them, the depths are going to understand what they’re trying to build towards. They might engineer a better solution in that process. But at least like we kind of knew what kind of experience we’re looking to go towards.
[00:30:53.340] – Ryan Williams
Let’s talk a little bit about the graphical side of things like so a part of this is a turnaround, right? So we actually have to, in the sprint process, were given a window for some initial meetings.
[00:31:04.350] – Ryan Williams
And then the second part of it is that once we come back with some very rough perspective on like let’s say we’re doing one feature within a sprint or a two-week sprint. Right? We come back with a set of wireframes and user flows after about three or four days that think through the user experience process of it. And then us a group meets again and they look at that and review it right? Now, that group says, OK, this looks good. I generally like the rough perspective of this and I can see the journey and I can see the layouts. And then there’s a next step, which is actually making things more high fidelity so that they go to the engineers in the right way. Maybe Joe, can you talk a little bit about like what are some kind of good best practices around, like expanding on those, but not overdoing it so that it can get into dev efficiently?
[00:31:56.170] – Joe Gillette
Yeah, absolutely. So, you know, with any project somewhere near the beginning, if it doesn’t already exist, you want to make sure that you’ve got a really good guidelines, like a style guide and a gooey kit. Most of the time. So, you know, having components, basically a component library that you can use to build just about any new feature. You know, your buttons look like this. Your forms look like this.
[00:32:25.440] – Joe Gillette
You know, pop ups look like this, etc. So, you get that in place pretty early on in a project. If it doesn’t already exist when you come on board. So that way, every time you design a new feature, every time you wire something, you give that to your design team. They’ve got a really clear guideline of how things should look within this environment. I like to give designers a little bit of leeway. Like, you know, wireframes are a guideline. And generally, especially with our team, I think we’re all really strong in UX and wireframing. So, like, when we deliver a wire, it’s usually a pretty, like, high fidelity wire. Like, we’ve really thought through the functionality, the user experience, the layout really well. But also, designer sometimes can bring really interesting ideas to the table that you wouldn’t necessarily think of. And, you know, especially when it comes to like those that Polish and those delightful moments that really make the user experience more rewarding.
[00:33:22.210] – Joe Gillette
So, I like to give them a little bit of leeway in that regard. What are some ways that we can make this more fun or more exciting or more interactive? But generally, you know, if you provide them with good requirements in the form of wireframes, I generally like to write some form of a creative brief, especially if it’s a new project. You know, we’re kicking it off. It’s the designer’s first time with this product or something like that, you know, kind of give them the lay of the land, you know, what is the client like?
[00:33:54.490] – Joe Gillette
Here’s some existing materials that they might have, some marketing materials that they like etc. But also, I like to similar with tech, I like to bring design into the conversation at least as early as possible. So maybe before I start wireframing, I’m going to let my design team know we just came out of this meeting. We’re going to go after this feature and this feature this week. So, it’s coming your way in about three or four days, just so you know. And they say, OK, great. You know, they can start preparing their team for the bandwidth. And then I start getting those requirements together, deliver those to them by the end of the week. And then they’ve already had a chance to get their creative wheels turning. And they can kind of take those requirements in and really build it into something, something nice.
[00:34:50.050] – Ryan Williams
Alexandra, how do you like to what’s the process of making sure that the designs come back? Like the way that everyone feels good about.
[00:34:59.780] – Alexandra Adelman
Review processes. Designs come back and meet with again. It’s all about stakeholder management and ensuring that everybody has a chance to see and weigh in on the final product that’s going to be delivered before it’s handed off to tech so that modifications can be made at a point when it’s the least costly to everybody’s time and money and energy and effort to make these changes.
[00:35:33.310] – Alexandra Adelman
Moving pixels is a lot cheaper than moving code. So, having designs come back and then looking at them from a product perspective to make sure that all the needs are met. But then again, I just keep coming back to the stakeholders, whether it’s business, marketing, a representative from the external user base, if it’s internal users just getting it in front of people’s eyes, who have the additional experience to weigh in and have an expert opinion. Yeah, that’s like that’s the only way that’s the only way to do it in a way that’s going to be just expensive as all get out and make everybody really unhappy.
[00:36:20.910] – Ryan Williams
Yeah. Just to add the that a little bit too I like to have somewhat of a preset feedback process where there’s not as much wiggle room as we think. So, a lot of business people like to look at something and just throw things out there. Which is great and OK. If we want like the tightest possible process, I love to ask them to actually write their feedback related to a screen or something like that. Usually we use a tool called Preview it. There’s about tons of imitation or feedback tools you can use in Invision. You can use sketch, you can use any of them like giving them a really simple place to like just give a piece of feedback and then you can take that in adjusted.
[00:37:05.030] – Ryan Williams
Can also record things. You know, obviously Zoom is a good spot here to let them look at it and then select their stream of consciousness, come out and collect that. But like either way that you’re actually hearing what’s coming back and then you’re going to translate that into the product vision itself. And then be able to do that same thing with tech, a lot of tech lab tech will come back with complex responses that they’re in their own space of, like actually looking at the puzzle of putting it together. So you capturing that and being able to bring that back in and say, OK, well, you actually mean is that the interface level we need this or on the data like on the data assessment level, we need this and you can actually translate those pieces effectively. So this part of the process where there is actually thought put into how you collect feedback and how you disseminate the feedback and it is a very undervalued part of the experience.
[00:38:05.240] – Ryan Williams
And if you actually put some time and focus into it, it can speed up your sprints exponentially. And part of that comes from the buy in of everybody to know that’s important. So, I just want to express that, put time and thought process into how you do feedback in your organization and try to make it very consistent.
[00:38:33.000] – Ryan Williams
All right. So, we’ll do kind of a last round with each of you. So, we’ve kind of got all these assets together. We’ve built the flows. We’ve got the wireframes. We’ve got some designs. We feel like we’ve done a couple of initial checks with everybody to make it feel like they’re really good with everything. And then we deliver. We deliver to the team. Right. Is there any kind of special process you like to do your deliveries or I know sometimes we’re in very fast sprint structures and we just like turn it in and it’s just like done?
[00:39:04.640] – Ryan Williams
But ideally how do we not drop like that thought process and context that goes into the things we’ve done in that delivery process. So, let’s kind of go around each of you and let you offer some feedback on that. Maybe, Joe, we can start with you.
[00:39:21.340] – Joe Gillette
Sure. Something that I found really handy is recording a simple video walkthrough. You know, having that voice over, you can provide some context. People can watch it and listen to it as many times as they need. Oftentimes we’re working with development teams that might be external resources, maybe in different time zones. So, it’s just like a really great way to kind of sum everything up and let them digest that material on their own time. And it’s also in a really sort of conversational way. Like you said, providing some of that context in that thought process is something that we do naturally as we walk through those deliverables. So, like, when I do a handoff and this is more for I would say this is more typical of a product that we’re developing from scratch. I’ll walk them through the entire thing. If I’ve got a prototype, I’ll walk them through the prototype with a voice over as well. I’ll walk them through the package of deliverables. But even so, in just a quick in an ongoing development process, if I’m handing off something that’s a new feature or a new design, I’m going to do the same thing and do a quick video walkthrough, you know, usually with a clickable prototype.
[00:40:34.750] – Joe Gillette
Here’s how it’s meant to work. Here’s what we were thinking. Here’s what the business needs. Here’s what the system needs to do, etc. And I just find that it’s a really good tool.
[00:40:53.220] – Amy Halvorsen
Amy. How about you? Similarly, to Joe, I would. We typically have meetings at the end of our sprint and we’ll do a walkthrough over a meeting. Sometimes they will call me in dev team or call me into specific meetings that they need more feedback on.
[00:41:11.400] – Amy Halvorsen
And I’ve also found that I leave very detailed prototypes and envision that have been really, really critical for Dev to see the process and how the design moves through the flow. And that’s been a really, really great tool for us to use.
[00:41:32.000] – Ryan Williams
Awesome thanks. How about you, Alexandra?
[00:41:36.120] – Alexandra Adelman
I think they both said it. I think they both said it all very well. Yeah, making myself available and being available to answer questions, whether it’s in a meeting, whether it’s through comments, just because that initial communication that both Joe and Amy mentioned is critical because it’s still a conversation like there’s always going to be some questions. So just ensuring that they have your information and that you’re available.
[00:42:15.060] – Ryan Williams
Yeah. And to add to that, giving that final piece of context here is why we’re at this spot so that they like understand up to this point what it is and they can actually keep engineering for the right solution. I actually think this is a great subject area for us to expand on in a future talk, because I think the communication between product and tech is obviously a vital one. And even just the handoff process for what the product requirement expectations are versus what actually comes out of tech like that actual point of synergy is like a really tricky one a lot of times, especially like Joe said, you might be working with people different time zones or different countries who speak different languages or completely different development methodologies. And then you’ve worked with in the past. But like that, communication has a lot of potential to affect the time and amount of money that’s being spent on a project. And again, it’s a little thing that if you put a little attention on it, it can dramatically affect the quality and efficiency of a project.
[00:43:25.480] – Ryan Williams
So, yeah that feels good. All right. Well, cool. I appreciate you guys taking some time to run through this with me today is awesome to hear your thoughts on it. And we spend a lot of time in these areas. So it’s good to be able to share it with everybody. And we hope you found it useful. So, yeah, I think we’ll wrap it up here.yeah, Joe.
[00:43:47.420] – Joe Gillette
I want to add a couple of things that are just like points that came up for me as we went along. So they might be something you can edit in or potentially just holding space for future discussions. So one thing was when we were talking about, like flows and why those flows are so crucial and why we don’t rush straight into designing the screens, laying out like true, truly detailed flows. That’s like the foundation for your inventory. Once you lay the flow out and you can see the user does this, the system serves this. The user does this. You start to see, oh, I need a screen here. I need a pop up here. I need another screen here. Then they go to this screen, etc. And it’s also it’s really important even for an existing product and especially for an existing product to understand like the holistic view of what you’re working on.
[00:44:39.580] – Joe Gillette
Like, you can’t just only focus on the feature, the new feature. You’ve got to think. How does this feature fit into the larger ecosystem of this product? And so that’s why flows are super crucial. Another thing that came up that I think is a really great point, and Alexandra spoke to this. Amy spoke to this prototyping and the crucial role that prototyping plays in stakeholder buy in, so to speak, and not to mention cost savings like a good just a dummy prototype, like a clickable, simple, clickable prototype.
[00:45:15.040] – Joe Gillette
Not even, you know, no dynamic data or anything. It goes so far in helping the client understand what they’re about to spend all their money building. And it can save them tons and tons of money in development to just play with it one time on a real screen to do it clickable. I really like envision for this reason, it’s a great place to collect consolidated feedback. You know, you can tag the image right on the button that you don’t like.
[00:45:42.430] – Joe Gillette
You know, you say this button. I wanted to say this instead. And everybody can put their feedback in one place. Your designer can take that feedback from one source as opposed to, you know a hundred emails from ten different people, all with varying opinions. We have a conversation now. Now we have a place where people are providing that consolidated feedback and then a prototype just goes so far in.
[00:46:06.090] – Joe Gillette
I think for clients, especially for business people wireframes are so abstract. No matter how many times they review it and they say, yeah, looks good. Looks great. Yeah, this is exactly what we need. As soon as they see it live, it’s a whole different conversation. So that’s why prototyping if you can account for it in your timeline and within your sprints and within your budget. I think it’s super important. Even just a quick clickable prototype goes a really long way.
[00:46:35.080] – Joe Gillette
And we’ve seen this across the board by several different clients. We’ve probably saved people tens of thousands of dollars, if not more, in engineering costs by doing a quick clickable prototype. And it immediately it doesn’t necessarily it’s not always uncovering problems. It’s not like, oh, we didn’t think this through. But it’s like now that I see this, I want something different, you know? And that’s like so crucial because if you spend all the money building it and then they go, actually, what if we did it this way instead you just wasted a bunch of money, whereas prototyping is like a much faster way to get that.
[00:47:12.490] – Joe Gillette
And then the final point I want to say, and it’s like one of the last things that we’ve talked to touched on, and I think you said this could be a future talk roundtable talk, that collaborative relationship with tech is so important. Having a good feedback loop between you and your development lead, your engineering lead, super crucial. Having a good rapport with them and a good relationship is super important. It’s kind of like, you know, if you’re like you’ve got to know who’s like your help. Your engineering team is your support. They’re ultimately going to build the thing and you want the product to be the best it can possibly be. And so you want them on your team always. So it has to be a collaborative relationship and it has to be an open dialogue as well. In my in my career, the best products that I’ve been able to launch have been where it’s like truly like an open, revolving door sort of thing with tech, you know, between product and tech.
[00:48:16.240] – Joe Gillette
It’s an ongoing conversation. If we’re developing over here in product, tech knows about what’s going on and they have a chance to contribute. Vice versa, like getting that continuous feedback from each other is super crucial to developing really good products.
[00:48:34.390] – Ryan Williams
Awesome. Thank you. All right, everybody. We’re going to end with that, some really, really good advice. And it was great to have you come and check this out. And we hope you found it useful.
[00:48:47.860] – Ryan Williams
We are Wondermentapps.com if you want to come check us out. We do this all day long. Feel free to reach out to us whether you want to learn more about how some of this stuff works or whether you actually have the need for some of this we’re happy to help there, too. But the other day, we just want to continue making better digital project products out there. And it’s more and more of it. And it’s great to be able to share some of the practices we do.
[00:49:13.930] – Ryan Williams
All right. Thank you all very much.