Gathering Requirements, And Rapidly Building Proof Of Concepts

Gathering Requirements, and Rapidly Building Proof of Concepts
Speaker: Tom Jordan
Thank you all so much for your time and thank you for choosing me over the beautiful sunshine in the canal. So here today, I have to start with the legally mandated disclaimer that all of the opinions are mine and not my parent company of Google.
So it's a big problem. Software is still failing regularly. It's failing too much as well. This data is from the CHAOS report, I can't remember the exact name. It says basically that two-thirds of projects come in overtime, over budget or they don't meet the initial requirements and 20% of projects fail to be delivered altogether.
So what's this talk all about? I'm going to have a quick high-level overview of gathering requirements, grouping, building prototypes from these requirements, and delivering success to your customers. What is it not? This isn't sadly an example of building a global app or the next big hit app that's going to take over the world and be massively successful. I, in my previous role at Econiq and Google currently, I focused mainly on building custom software for people, with an idea to scale it out to other customers but it's very much a personal one-to-one process with individual clients, going outside, meeting them, talking to them, building something that satisfies their needs.
The main areas I'm going to focus on today are having effective conversations with your customers, discovering what they actually need, not what they say they want, grouping all of these notes you'll get into requirements and then iteratively improving and building prototypes from these requirements. So the mistakes I've made and they are common mistakes, I still make them as one of the reasons they're making this talk is to reinforce that with myself is, I jump to solutions too quickly. So when someone is talking, I'm like I can solve this and you don't effectively listen. I make unstated assumptions, which everyone does. They're like, "oh yeah." Now I know what this is. I've seen something like this before. Everyone is different, everyone is unique, and trying to rush through and deliver something too quickly can be an issue. So, I'm going to start out telling you probably my worst mistake. It was the biggest learning experience of my career. So it worked out well. I think all mistakes should be learning experiences and essentially was working with a large insurance broker and they had a simple ask. They wanted to build a lightweight CRM system. They said sales force is too much. They didn't have anything on the market. All they wanted is a simple way to track their leads, really lightweight, really easy to use, powerful and customised for their needs.
So, I said ‘how hard can it be?’ I was just after a successful project. I'm like I can do this. This is fine. This is the Greenfield project that I've always wanted. After four months, I think we're receiving 10 new feature requests a day. Everyone was unhappy. People were snapping at each other. We were assuming the worst intentions from our clients and stakeholders. They thought we weren't delivering. There was just poor communication all around. We were feeling burned out. I and my coworker were working 15 hour days, trying to deliver features on time and in the end, the project was a complete and total failure.
What went wrong? The first thing we failed to do and it's easily overlooked is building rapport with your customer. It's super simple. Just taking the time to actually talk to people, get to know them, make a bit of small talk and avoid being seen as a transactional person. You actually become somebody who's there to help who listens to their problems. Even just chatting about personal things, a bit of research in the person, talk about football, talk about how the company is doing and talk about how they meet their targets, just that kind of thing. Get to know them. If you're really desperate, you can talk about the weather but it's hard.
The next stage is to ensure to always ask open questions. It's too easy to have, especially when you have an idea in your head already, you ask yes or no questions to validate your idea and you don't get that rich data and that rich knowledge that comes from talking to your customer one to one. So, there are a couple of examples here. Why isn't it working for you right now? What goals do you have in general? What does success look like for you? There are lots of other ones that come naturally. It can be difficult to do this and it's easy to slip back to really simple yes, no questions. Like this avoiding: closed questions. So even there it's like, do you think it'll be useful? It's like, that's not a great question. You can just say, ‘what do you think would be useful about this product? What do you not think would be useful about this product?’ Get kind of positives, negatives as best you can and work forward that way. Finally, very trendy at the minute but actively listen to the customer again, don't come up with solutions while they're talking. Really carefully listen to them, summarise what they've said. Repeat it back to them to confirm that you understood their needs correctly and summarising and confirming will be a common theme today. It's vital at all stages to ensure that you've accurately understood what people actually want.
Similar to earlier with the five whys, I actually vaguely heard that it before but I hadn't used it that way. I generally find I deal with different kinds of stakeholders of clients. Some people are very detailed-focused and it's very difficult to get them up out of that level. So I always ask why questions. So, why is that important to you? Raise them up and try to understand their high-level goals and their midterm tactical goals. Other people are very vague with what they want and it's important to ask, how exactly do you want this to work and get them down into details and really get a hard understanding of what that's going to look like. So when do you use these skills? Use these dealing directly with customers but also vital skills from dealing with internal stakeholders. I've used them when I've taken over projects midway through, used them with your manager or the person handing them off saying why did you make these decisions? Try to deeply understand the reasoning behind every decision and even in large public-facing things with lots of user of research and other inputs, these are still vital skills to know for your stakeholder interviews and other parts.
Next, you have a ton of notes. I think some of my colleagues have referred to my notebooks as looking like a serial killer's notebook. So to try to bring order to chaos, I generally lean on one of the oldest ways people have brought order to chaos: through storytelling. So you try to identify your main needs and group these together into narratives and general stories, which then define the user's problems and different solutions we could have and it becomes a kind of user story like you'd be well used to. One extra step I'd like to take is from Alan Cooper is to build an overarching problem statement that clearly defines the problem for the customer at a high level. This example here was taken from a recent project at work. It's an internal facing product for our salespeople and people are just finding it difficult. They want to create stuff for YouTube but they've no idea what to create there. So much out there, no idea to tell what's popular, no idea to tell like, is it oversaturated? From this you're able to, again, it's essentially a very high level summary, which you can then confirm, is this actually a problem? And will my vision statement actually lead towards a solution? And the vision statement is there to act as a guide for everything you do from then on. So you think, okay, I'm going to add this feature. Does this align with my vision statement? Is this relevant to what I'm going to do? And I think this ended up just being a basic dashboard.
Now onto the fun stage where you get to actually start building some prototypes. Depends on different projects. I skip many of these stages. Obviously, if I'm building an Extract, Load and Transform (ETL) pipeline or if for building a standard data processing workflow, you don't really need to be showing people a beautifully mocked up user interface (UI) of something that doesn't exist.
The first one I always start with regardless of the project is quick and basic paper prototypes. I didn't draw this one because my drawings are similar to my notebooks. They're a bit of a mess. So, I actually personally preferred almost to whiteboard iterations. So if I have a chance to sit in the room with my colleagues or sit in the room with my stakeholders to actually sit there and draw my solution freehand and explain what I'm doing at each step and really communicate that through and ensure again, it's what they actually need and what they want.
I then like to move on to low fidelity prototypes personally, doing these using PowerPoint software. So I've used actually all three of these. I should probably be pimping at Google slides but to be fair, they're all perfectly good for this use. In this case, the master slide is your friend. Create a master slide of your basic UI navigation and you can just reuse that for all your different applications states and you actually, by that stage, you're already doing the grouping, your application into components. You can identify reusable components and it's a very powerful tool. It depends on your stakeholder and on your client. Some people, if you give them a low fidelity prototype, they look at it like, "What is this?" Even, if you don't share it directly with your client, it's a really good way to validate your ideas and ensure that what you're planning is actually going to work.
Now, this is just a short sample. I haven't even used half of these. I have used Sketch, Envision and I think Adobe XD I gave a go as well. They're all perfectly fine. My favorite is Figma. I don't know if any of you have used it. I think it's fantastic. It lets you collaborate in real-time. People can comment on it. You can bring in other people to get feedback, direct feedback and you can generate really cool, really powerful, interactive prototypes. I am going to pimp out Figma a lot even though I don't work for them.
And finally, I like to build a functional prototype. So I'm not even sure if there is a real term or the accepted term but essentially I like to start building the UI in the front end if applicable. I usually use a framework. Personally, I like Angular GS. However, I don't like Angular now, which is a bit awkward where I work at the minute. React seems cool but the first time I saw the JSX and HTML I thought, ‘ah, I’m not going near that’. So I stuck with View. And one of my last major UI projects was actually built in a large meeting planner kind of check-in application and the cool thing is you can build your entire front end just and dummy JSON objects in the back end and changes are really quick.
You don't have to touch the server side, you don't have to touch any data layer. And you can give fully functional applications to people which will then form the basis of the app. And once you've iterated that, got user feedback, got a front end that works well. Then all you have to do is implement the backend services and you've developed a fully-featured proof of concept in hopefully record time.

• That would be a success I conclude. The key elements I like you to take away today are to:
• always listen really carefully to what your customers are saying
• summarise what they've said and repeat it back to them
• make sure that what you think and what they think they said are perfectly aligned
• rapidly iterate and test everything as best you can
  In this way, I hope you'll actually build products that your customers want and need instead of building products and search solutions.