SPONSORED BY INTUIT On today’s episode, Ben and Ryan chat with Himanshu Sharma, Staff Software Engineer at Intuit, about their processes for rapid prototyping. Rapid prototyping has a deep history at Intuit, starting from their very first product design. They talk about how that process went notes on a scratch pad at a kitchen table to a repeatable and reliable process baked into the culture of an organization the scale of Intuit.
To learn more about technology or careers at Intuit, visit intuit.com/technology.
Want to read more about rapid prototyping at Intuit?
To connect with Himanshu, find him on LinkedIn.
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. Today we have a sponsored episode from the fine folks at Intuit. I'm Ben Popper, the Director of Content here at Stack Overflow, joined as I often am by my colleague and compatriot, our Senior Technical Writer, blog editor, and email maestro, Ryan Donovan. Hey, Ryan.
Ryan Donovan Hello, Ben. How’re you doing?
BP I'm good, thanks. How are you?
RD I'm doing all right.
BP So you and I talk with developers and tech leaders every day. One thing people care a lot about is velocity– how fast are developers getting product to market, how fast are folks iterating, and what kind of impact is that making at the organization? So today I'm really excited. We're going to be chatting with Himanshu Sharma from Intuit all about his journey into a world of rapid prototyping, that this is now something that's getting baked into the culture at Intuit, and a bit about how he learned this process and kind of brought it to life within the company. So Himanshu, without further ado, welcome to the program.
Himanshu Sharma Hello, Ben. Hello, Ryan. Happy to be here.
BP So tell us just real quick, how'd you get into the world of software development and how'd you land Intuit?
HS I was listening to a few of the other episodes on the Stack Overflow Podcast and it's shocking how for many people the gateway drug for programming was video games. It's pretty much the same with me as well. I got a PS2, I remember, and I was playing a whole bunch of games and that was my big introduction to tech. And the first time I learned if conditions, it was so shocking to me. I was just thinking about how there must be an infinite amount of if conditions in that game for all the different combinations you could do, and that was my first foray into programming. And then in middle school, I kind of got into web dev. I loved using the marquee scrolling on an HTML website. That was kind of where I actually started going into tech. I knew I had an interest. I joined the University of Toronto as a computer engineer, and once I graduated, I actually joined Intuit. And since then, I've kind of worked all across the stack at Intuit. I started off on desktop, then I started doing some service back end work, switched over to front end. I've dabbled in data science and machine learning and I've also done some non-tech stuff as well with scrum management. So that's kind of been my tech journey since then. Currently, right now I'm a Staff Software Engineer and I work on our tax platform, so I'm focusing on simplifying taxes for professionals across the US, Canada, UK. And like you mentioned rapid prototyping, we’ve got to do it quite a lot in my role.
RD I'm excited at the rapid prototyping conversation. Everybody talks about failing fast, and I think rapid prototyping is a big part of that. When we talked earlier, we talked about how rapid prototyping is baked in from the beginning, the very beginning of Intuit. Can you share that story? And then kind of talk about how you went from there to a more formalized rapid prototyping culture.
HS So you mentioned it right there– from day one at Intuit it's kind of been part of our culture. So there's a whole myth– and I wouldn't even call it a myth because it's pretty much reality– our founder Scott Cook, he saw his wife on a dining table trying to do her books and just seeing her frustrated there was kind of his first aha moment. And this is when software and computers were starting to become big, so he thought that there's got to be a better way. And he kind of followed her to her office, saw what he could do better, and then worked with her to create our first products. So that's kind of where it started, so from day one, it's in our DNA, but taking that one instance and formalizing it took a lot of years. So the way this whole thing happened was that Intuit started becoming a big company, we started building a lot of products, a lot of features, and what we noticed was that there were some teams that were more successful than others, and we wanted to see what was that special thing that was the difference between these successful teams and the non-successful teams, and that's kind of where this process got formalized. So in essence, we figured out that there were two big themes. One was what problems we were trying to solve, and then two, how we are solving them. So in terms of what problems we are trying to solve, that got formalized into what we call now as customer-driven innovation or CDI, and essentially that has three pillars. We want, as Intuit, to choose an important unsolved customer problem, so any pain point where there's no good solution. Then once we have that, we want to be able to solve it well. We don't want just a band aid solution, we want something that's truly delightful and blows the competition out of the water. And then lastly, we want to build a durable competitive advantage. So we're a business, we want to make sure that we can deliver something that's durable for the long term. So that's the what we saw, and then we came to the how we solved it. So again, this was looking in and looking out. A lot of research was done into what successful teams at Intuit were doing, what successful teams and products outside of Intuit were doing, and that's where the D4D or design for delight part of it comes in and that's where rapid experimentation is also a part of this process. So there we realized that in design for delight they've figured out, okay, all of these successful teams really know their customers well, so that was step one– deep customer empathy. Then once they figured out that these teams know their customers, they would literally go broad, think of any possible wild solution out there, and then they would narrow it down and figure out the assumptions that were involved in there. Then that's where the rapid prototyping actually comes in. So once you have these assumptions, instead of building out a whole software, giving it to the customers and then realizing that you're going to fail, that's where the rapid experimentation and rapid prototyping comes into play where we build prototypes as quickly as possible, get them to users as quickly as possible, and then iterate based on the feedback. So that's kind of the whole story of it in those three big sections. We keep evolving it as we learn more as we see what's going on in the industry. That's kind of the whole story.
BP Nice. So let's put this into practice. You're talking about it sort of in the abstract, but I know you've worked on some projects recently that went through this cycle. Can you share some with us so we can kind of get into the nuts and bolts?
HS There's one really big one that comes to my mind. It was probably one of the most challenging projects I've done ever. So the big inciting incident for this was– like I said, I'm on the tax platform, and in Canada we had a very solid desktop application but we did not have an online application. So our team was given about three-ish months to launch a brand new tax module on a new online platform, like in QuickBooks for example, with a very small team. So we had 10 devs and two designers, and we had to get all of this done in three months and out into production. So that's kind of where when we started the process we were thinking about doing the classic thing of having our designers and PMs go out, talk to customers, come back with feedback, and very quickly we realized that wasn't going to work for us because we just didn't have the time. So instead we kind of deep dove into this rapid prototyping work experience. As part of this whole project, we spent around 500 hours with customers across the whole team, so not just designers, not just PM, engineers, and in fact, I'm almost 100% certain even sales and marketing folks were involved in the whole process. So we spent 500 hours throughout the team understanding who our customers were and what their problems were, and then we actually did what we call ‘Follow Me Home’ and ‘Follow Me to the Office,’ FMOs, obviously with consent. We didn't just stalk our customers and follow them home. And the whole point was that we would go in and we'd see exactly what they were doing and kind of take notes. And it's so easy to actually see what they're dealing with when you can see on their face what pains them. So we kind of did that as a first part. Like I mentioned, there were three big pillars in this rapid experimentation prototyping phase. So that was the first one, and after we did this, we had a very strong understanding of who our customers were, and then we went into the solution generation. So here we used a whole bunch of techniques– classic brainstorming, everyone coming into a room pitching the wildest ideas you can think of, nothing is too crazy. So I remember we had discussions about, “Hey, wouldn't it be great if they didn't just have to do their tax, if someone just did it for them?” And we were like, “Yeah, throw it on the board.” And then we were talking about, “Oh, what if we have a fully AI-driven solution where you just have to hit one button and taxes are done?” “Great, throw it on the board.” So once we had those ideas, we started doing some other practices as well. We thought about ideal state thinking. It’s something we do a lot where we think about, “Okay, in a perfect world, what would our customer's life be like?” So there we thought about things like that they would never have to enter any data, for example. All the data would just flow automatically, one click for taxes. And what we learned very quickly was that customers don't like doing taxes. They like looking at the taxes, looking at the data, and then actually giving some insights to their customers. And a fact that always astounds me is I think 50% of small businesses fail in the first five years, and a big chunk of that are businesses that don't have an accountant supporting them who is not giving them insights. So that was something that really hit me. So that's something that we wanted to take. So now that we have these ideas, we kind of wanted to test out and prototype these. So even our craziest ideas, like I mentioned that live tech support, the live expert support, you're like, “Okay, we want to prototype this. We want to see if it has legs.” And then the second, one other really big one that I remember, their prototype was data integration, not having to enter data again. So once we had it narrowed down to these few ideas– and narrowing down there's a whole bunch of processes for that as well. The ones we used in my team was multi-voting, for example. Everyone had 100 points to throw on ideas that they think are the most impactful and that kind of helps us narrow it down. Then we made a giant 2x2 grid on a whiteboard, and with the stickies that we had we kind of had actually a whole bunch of 2x2s where we had on the x-axis how innovative the solution was, how much of an improvement this would be on the current problem, and a whole bunch of these metrics that we threw our ideas on. And again, we picked the top two there. Then once we had those ideas, we actually literally took pen to paper, didn't write a single line of code, engineers and designers in the same room and kind of just literally drew what we thought the solution would look like and we took it to our customers. We had lots of sticky notes and pens at the ready and we literally just went to our customers, showed them, “This is a new tax software. Imagine, use your imagination, click through, tell us what works, what doesn't work.” And at this point, the main thing was kind of figuring out what our assumptions were and validating them. So as they were going through the design, if they said something like, “This kind of doesn't look right,” rip out a piece of paper, make it how they think it looks right, throw it on there. And that kind of just helps us not maybe design the perfect solution, but kind of get an idea of where our assumptions were right and where our assumptions were wrong. And kind of the main core of the prototyping experience was literally just ripping papers, putting it on, and I think the one that I really loved was that live expert thing. We took an iPhone, we stuck a piece of paper on top, and we showed it to a customer and we were like, “This is your live chat,” and we actually had an expert in another room FaceTime the iPhone and we were like, “Hey, look at this. You can ask them any question.” And it's burned into my brain, the memory of them looking at the iPhone and just the wide-eyed look that they had. That was something that, in my opinion, you can't get with any other experience out there. And that kind of immediately gives you that your assumption is proven now, you know that it's right. So that's kind of the whole process. Then we took all of that, combined it into a final solution, did some more clearing up, made sure the data backs what we saw qualitatively as well, and then in the end we were able to make this project. We were actually able to ship it out I want to say maybe a week or two ahead of time. At the time, it was a record high NPS of over 50 for a first-year product, which is great. It was delivered, like I said, on time, no critical bugs, no P0s, no P1s. And we did our own calculations from Jira figuring out our velocity and how much time was spent in meetings versus actually coding. We noticed a 53% bump in developer efficiency, which is great to see as well, and more qualitatively as well. In all of our sprint retros, we do a little developer happiness score and that got bumped up from, I think, the low 7’s up to mid 8’s to high 9’s. Happy developer, happy everyone. That was the whole experience.
RD I kind of want to figure out what happens when you run into an assumption that was wrong or a prototype that failed. I like to joke with folks that the first step to being right is being wrong. So could you walk through one of those decisions or bugs that you thought might be right, but when the rubber hit the road, it was the wrong thing to do and how you captured the learnings from that?
HS I don't want to sound like a dad here, but you know what they say about assumptions. When you assume, it makes an ass out of you and me. But like you said, such a core part of this rapid prototyping experience is that you have to make an assumption. One that I remember off the top of my head is– and it's kind of shocking when I say it out loud– our customers did not expect our web application to work like a web app. We assumed that we're on web, we're going to follow web practices, everything is the same, we're going to make sure we're following all the standards, but our customers were accountants who up until this point were on a desktop software, and they were also power users. They had their key bindings, they had their shortcuts, they hated using the mouse. They were like, “I spend so much time clicking on this and that and the other.” So in our first design, we had a very amazing responsive web dev app. We were like, “Okay, here's a mobile view on a piece of paper. Here's this, that, and the other,” and very early on we got the feedback saying, “I would never do someone's taxes on my mobile,” which makes sense. That's not the customer we're dealing with here, so that was a learning there. And literally in one of those sessions while we were talking to them and they were like, “Ugh, I have to click through all of these,” one of our engineers took out a piece of paper, drew a little search bar on it kind of inspired by the Mac omnibar, and he was like, “Here. Here's a search bar. Would that work if you type something in?” and immediately was like, “Yeah, that'd be great.” And then the question became, “What can I search here?” That's where you can get the gold out of them and be like, “What would you want to be able to search here?” And that's kind of where we started off with a failed assumption where we thought, “Hey, it's a web app. It's going to work like a web app,” and very quickly we corrected ourselves. In one or two sessions, we were able to iterate a bit more and now that search bar is a key feature of our application. You can search for literally anything and everything, like text within thousands of tax forms, and it also improved accessibility as well. As a complete side tangent, now you can complete anyone's taxes using our app using just the keyboard. So not only did a failed assumption actually help us learn something very quickly, very cheaply, very efficiently, but also made the product better for everyone else. But that being said, the one thing I do want to make sure that I get out here is that it's super cheap and easy to fail in safe mode while you're doing rapid prototyping. Especially when you're a company like Intuit and you're dealing with sensitive financial data, it's a lot better to have an assumption and have it fail in rapid prototyping rather than actually scale out and put something out there that's going to fail. So even though we have lots of safeguards to make sure none of that happens, it's so much easier and cheaper to fail and fail quickly and as many times as you want.
BP It's interesting, you've talked a lot about sort of working in paper, going along with people to their office or to their home. Can we talk a little bit about how engineering and design work together in this process? When you get down to the nuts and bolts of it, like you mentioned, meetings versus time actually coding, how do you get engineering and design working well together from a sticky note to the actual tech stack and the development of the software?
HS So the one thing that's different in this process that I've noticed compared to other more generic ideation problem solving methods is that everyone– engineers and designers and PM– are part of the problem solving from day one, so there isn't that silo where this job is just a designer's job, this job is just an engineer's job. And in my own personal experience, what I've noticed is that designers are idealists, they can be idealists, and engineers are pragmatists. So I know for myself, I can come into a meeting and I can tell you a hundred reasons why a solution won't work, and at the same time, designers can look at a problem and think of this ideal, perfect solution that would work for everyone and everything, and you take one look at it and you're like, “Oh, that's not going to work.” So that's where a lot of the butting of heads can happen, but in my opinion and in practice as well for me, if you're not butting heads, if there's not a bit of tension in there, then you're not doing your job right. So kind of the one thing that helps out is everyone has that same idea. We all know who our customers are, so having the designers in there, they're still in charge of the design but it's not just their job. As an engineer, you're part of the solution, you're coming up with ideas. They're there to help you get your ideas onto paper, onto designs, Figma or something as well. So it's not as much of an issue of them doing their work, us doing our work; it's more of a collaborative effort. And again, the one thing we can always fall back on is what is right for the customers. So a lot of times we might not agree on a decision, but then we go back and say, “Is this better for the customer or not?” And again, from the actual process perspective, it's literally everyone in one room. You're in one room, there is no wrong answers, and everyone comes in with a positive mindset. So you get your ideas out there, the designers are much better at formalizing them into something that is presentable, and that's kind of how that dynamic works, but it's very important for both parties to be in the same room from day one.
RD I wonder with that, a lot of this process seems to be very much face to face, sticky notes, people in the same room. How do you scale that across an organization as large as Intuit?
HS That's a great question. Intuit is a big company. There's, I believe, around 18-20,000 employees all across Intuit. And the fact of the matter is that it's difficult to scale the same in-person thing out to scale this big, and especially when you have folks working across different geographies to solve the same customer problem as well. We have teams all over the world. But what helps is that everyone has the same guiding principles to begin with. So the CDI and D4D process is kind of baked-in from day one. When you join Intuit, we kind of train you on it. In fact, one of the things I had to do on my onboarding was make sure I did a Follow Me Home in the first month that I was at Intuit. So essentially we start from a bottom-up approach where for every single person it's understood that part of their job is knowing how to do this and being good at it and kind of building that skill. So for example, in our last Global Engineering Days, which was a hackathon that we had all over Intuit, we have literally a team that is dedicated to customer connection. For my project in particular, I was trying to figure out how to use Gen AI to create a question/answer for a tax form where tax content developers could ask questions to the actual tax forms. I needed some help figuring out who these people were, who I could talk to, and we have a whole team whose dedicated job is figuring out who the right customers are, bringing them in, whether it's virtually, whether it's in person, and giving you an opportunity to talk. So that kind of helps having a dedicated team that allows you to focus on actually doing the work and not on everything else that's around the process. And then more importantly, now these days, like I mentioned with the advent of AI, this can so easily be supercharged. It's so cheap and easy to test out with the different models out there. And since they're trained with general human public knowledge, you can use them as a stand-in for people. And furthermore, you can use this as a brainstorming tool. Literally, you could do a hundred brainstorming sessions in five minutes.
BP I think one of the things that's been really cool to see there is what folks are doing on the design to front end. And you mentioned you go through this big sprint, you have the stuff in paper and in real life, you throw out assumptions, but then when you write it, you kind of also wanted to note, “Hey, look, there were no serious vulnerabilities here.” You said P1, P2, you have them in your organization, but you can now literally take a Figma file, throw it in one of these Gen AI apps and it'll say, “Okay, I know what your front end should look like. Here's an interactive interface. Okay, if you want to change that up, add a few adjectives and we'll change it up.” So it really does kind of get your brain cells firing to be able to have that quick call and response.
HS 100%. And I'm sure every company has their own set of Gen AI tools. For us, like you mentioned, we have our own design to code pipeline where now it's even quicker for us. Once we have the designs done, we basically already have the components ready there ready to ship out. That really, really helps scaling up vastly. It is so quick now.
BP What's the design to code pipeline and a little bit about components? I think our audience would be interested to hear that.
HS So our main go-to solution for design is Figma at Intuit, and we also have our standard library. So we have our Intuit design systems where the whole grammar of our design is in there. It's our Bible for design. So anytime we make a decision, anytime we are choosing components, how to render something, literally a whole guideline is available there. Those components are drag and drop into Figma. So that's kind of how we can also make kind of realistic prototypes as well. When it comes to that type of prototyping, we can just drag, drop, create a whole flow, have it run through a prototyping session. And then there's two ways right now at Intuit where we take that code and put it into production. One is kind of what we talked about a bit earlier– the code generation, the automatic code generation– and the second one is more manual where we have scaffolding involved where a lot of this code is generated and then we go in and do the final work. So as long as that work is done up front with designers and engineers, the end product is a lot faster to get out. And we're a React shop, we're TypeScript, so we use everything that's out there to make sure we can deliver with speed.
RD Interesting. So it sounds like the development process here is almost entirely in the design side, in the upfront.
HS Ideally, that is how it should be. A lot of times it isn't. Like I said, I'm the kind of guy who comes into a room and tells you, “No, we can't do this,” and it's better to say that up front and quickly. So yes, we might have designs that look good, but at the end of the day, if it's not feasible and we only talk about the front end, there's a whole bunch of stuff when we talk about the back end, when we talk about safety that's involved, security, all of that stuff has to be thought of. So just even beyond the basic design, when we start talking about architectural design, system design, we have a lot of paved roads at Intuit. Our whole data pipeline is pretty much ready to go. It's a drag and drop pipeline. We have our own HTML renderer that helps us render tax content super easily. So there's a lot of picking and choosing, figuring out what box would work best for the solution and then making sure that it works at the end of the day.
[music plays]
BP All right, everybody. Thanks so much for listening. Hope you learned a little something. It is that time of the show. We want to shout out someone who came on Stack Overflow, shared a little knowledge or curiosity and spread that around the community. Awarded seven hours ago to RobW, a Populist Badge for providing an answer so good that it got more upvotes than the accepted answer: “What do I do? Git is refusing to fetch into my current branch.” Yikes, you need some help with that. Thanks again for the answer, Rob. You've been given the Populist Badge and helped 88,000 people who viewed this question. As always, I am Ben Popper, Director of Content here at Stack Overflow. Find me on X @BenPopper. Hit us up with questions or suggestions for the show: podcast@stackoverflow.com. And if you liked what you heard today, leave us a rating and a review, or subscribe to get some more.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find it at stackoverflow.blog. And if you want to reach out to me for any reason, you can find me on LinkedIn.
HS My name is Himanshu Sharma. I'm a Staff Software Engineer at Intuit. The easiest way to find and reach out to me is on LinkedIn– Himanshu Sharma Intuit on Google will get you. There's a lot of Himanshu Sharmas, but that'll get me. That's it.
BP All right, everybody. Thanks for listening, and we will talk to you soon.
[outro music plays]