We have a special bonus episode of the Salesforce Admins Podcast for you today, where we talk to Justin Kuryliw, the project manager for the Salesforce Crisis Response App. We learn about the process behind building and deploying this app so fast.
Join us as we talk about the importance of recruiting a team and delegating to them, why they spent two days planning out of the week they had to build, and why teams need to overcommunicate.
You should subscribe for the full episode, but here are a few takeaways from our conversation with Justin Kuryliw.
In his day-to-day life, Justin is a Solution Engineer at Salesforce. “Normally, what I do is focus on helping Salesforce customers architect solutions,” he says, “but the project that we started is a crisis response app to help Salesforce customers with COVID-19 in helping to track employee and location impact.” This app, which you can download on the AppExchange, allows companies to keep track of whether or not their team members need to self-quarantine, or even just mark themselves as safe.
COVID-19 has drastically changed things quite quickly, so time was of the essence. They started with a paragraph description of what they thought the app should do, while at the same time having conversations with customers who might have a need to find out if they were on the right track. They refined these ideas into potential features based on feedback, which allowed them get buy-in in further conversations and recruit more members for the team.
“The best feedback we got was when we actually showed the app to people and gave them a chance to react,” Justin says, but they could only start doing that by building an MVP. They put it in front of people who never used Salesforce—their dads—which let them see where they could add in-app help features to make it easier to use.
As the team added more members, Justin needed to focus on coordinating his team while still keeping things fast and nimble. He recruited people and transformed the features from his description into products, making each team member a product owner so they could divide and conquer. They coordinated via a working document to make sure they always knew who owned what, as well as what roadblocks they were encountering in their work. This document guided their daily standups and kept them on track through their two-week development cycle.
Justin was building this app with a four-member team, and they all were still doing their day jobs, so communication was key to being able to work quickly. “Two weeks is not a lot of time when you consider that that was design, that was building, that was testing, and that was deployment,” he says, “so really we only had four or five days to actually build the app.”
“When you have four different people building the application, consistency starts to become very challenging,” Justin says, “so every other day we’d demo what was new and what was built for each other.” In the first two or three days of work, they published design principles to align the team: have little to no impact on production objects, make it user friendly, and use less code. Using Lightning Flows, Lightning Pages and other declarative tools helped them accomplish that vision and deliver an app with only four Lightning components and a relatively small amount of Apex coding.
They spent two days of their week of building just on planning. “We got a lot of value out of making sure that we all agreed on the data model, we all agreed on what was in scope and out of scope,” Justin says, “so when we finally put hands to keyboard nobody had any questions about what needed to be built.”
Mike Gerholdt: Welcome to the Salesforce Admins Podcast where we talk about product, community, and careers to help you become an awesome admin. I’m Mike Gerholdt.
Gillian Bruce: And I’m Gillian Bruce.
Mike Gerholdt: And joining us today is Justin Kuryliw, the project manger for the Salesforce Crisis Response App to talk about how Salesforce communicated, prioritized, and got sign off to build and deploy an app super fast. Gillian and I both agree that this is super important for admin. So if possible, take notes so that you can deploy a solution as fast as possible. And with that, let’s get Justin on the podcast.
Mike Gerholdt: So Justin, welcome to the podcast.
Justin Kuryliw: Thank you. Thanks for having me.
Mike Gerholdt: Well we’re excited to have you on and talk about everything that Salesforce is doing right now. So let’s kick off with a little bit of background on what you do at Salesforce and the project that you’re on that Gillian and I both feel are very relevant for what admins are working on.
Justin Kuryliw: Yeah, so my name’s Justin. I’m a solution engineer at Salesforce. I’ve been at Salesforce for around seven years, and normally what I do is focus on helping Salesforce customers architect solutions.
Justin Kuryliw: But the project that we started and that we’re talking about today is a crisis response app to help Salesforce customers with COVID-19 and helping to track employee and location impact. And we formed a team to deploy out to Salesforce users, a way to basically download that from the app exchange and easily manage and address employee issues.
Justin Kuryliw: So for example, whether an employee needed to be self-quarantined or wanted to report themselves as safe during a crisis, we built an app within Salesforce using custom objects and flows to help companies do that.
Gillian Bruce: That’s awesome. So I know that this has created quite a buzz in the Salesforce community and it’s an incredible app on the app on the app exchange that people can access. I’d love to know kind of how this idea came to you, your team? Like how did you take this concept and start creating an app from it? Because I think a lot of our admins right now are in a position where they’re seeing new needs from their businesses and they want to create solutions. They have the tools, they know how to create flows, they know how to create data models and all of that, but how did you take this from an idea to an app?
Justin Kuryliw: Yeah, so the idea actually came from working with one of our potential users of the application. It was a company that’s around 5000 employees and they had mentioned to us that they’re just busy. The CIO was saying, “We’re really busy right now with COVID-19,” and we asked, “What exactly are you dealing with? How can we help?” And it turned out that they needed to quickly stand up technology for tracking employees that were impacted by the ongoing crisis.
Justin Kuryliw: And so, as a solution engineer, as many admins would think like, “All right, how can I spin up a really quick Salesforce app to deal with this?” And that’s really where it came from.
Mike Gerholdt: So step two of that in my head is, “Okay, I’ve got somebody that needs something, what are all the features?” Like what was the methodology for you to collect requirements around what you wanted to put in and how did you also then kind of vet like what’s going to make the cut and how do we get a minimum viable product out?
Justin Kuryliw: Yeah, so we took that initial discussion and put it into a larger, more thought out single paragraph description with some bullet points of features we would potentially build, and validate it with some other potential users, in our case, other companies, and started asking if they would find an app like this beneficial. And we got a lot of early feedback. Some said, “These sections wouldn’t,” some said, “Everything would be great, we’d install this immediately and use it.”
Justin Kuryliw: And so that was early on. And once we started collecting that feedback, we started putting it into a working document. And at the time, it was really just me. So when I say we, the team kind of grew over time and we recruited those that we needed along the way and started building out in more detail of what we would think those features would entail, just to continue to get buy-in and continue to build out our vision.
Justin Kuryliw: And as soon as we had it in that document, it became a lot more easy to talk about, gain buy-in, recruit members of the team. And then each of those features ended up becoming what we call the products and each person took ownership of one of those products and ended up building it out.
Gillian Bruce: So I really like how you say that you kind of created a paragraph description of what you thought this solution should be and you shared it to get feedback and kind of use that as your starting point. I think, you know, having that vision and being able to get buy-in from others or just get collaboration from others, using that as a starting point I think is really, really important.
Gillian Bruce: I mean, we talk about that at Salesforce, we have that [inaudible] concept and I think this translates into kind of developing products and developing apps because you’re doing a very similar thing, right? Like, “Hey, I have this, the goal is to accomplish X, Y, and Z. These are the ways I think we’re going to do that.” You said you gathered feedback from folks. Like did people get really excited once you started sharing that paragraph, sharing that vision that you had? Were people like lit? Were people like, “Oh my God, what are you doing?” Tell me a little bit about that experience.
Justin Kuryliw: You know, I would say most of our users were, like most of the responses I got were, “Yep, I’d use that.” And you’re expecting a big, like you put all your effort into this and you’re expecting this huge piece of feedback that this is awesome, but a lot of them either didn’t reply right away or gave a quick yes. And so, the most helpful feedback we got were the constructive feedback, but that was also the hardest to get.
Mike Gerholdt: I could believe that. I think it’s always easier human nature to pick something apart than it is to define positive things or things that they would add to it, right?
Justin Kuryliw: Yeah. And really, like the best feedback we got was when we actually showed the app to people and gave them a chance to react. So after we started building it, we would have, for example, my dad or Claire, who’s a member on our team’s dad walked through the app and just tell us what they didn’t get, right? Because we wanted to make sure that it was easy to use. And so we brought people in that we knew had zero experience with Salesforce at all and saw if they were able to use the application.
Justin Kuryliw: And so when they were in there, having no context of the application, not even a description, we were able to really get some good feedback on what features they used, what features they didn’t use, and that informed our roadmap of what we would want to focus on. And that actually informed for us a lot of effort going into in-app help. Like we created a welcome tutorial and we created some help sections within lightening pages where it’s just rich text on the page to help them understand how to use specific features. So that was very helpful.
Gillian Bruce: I love it. It’s like the dad test.
Mike Gerholdt: Literally the dad test. Justin, you mentioned communication a lot and I think for some of our admins that are part of teams, this was an incredibly fast, incredibly nimble effort. How did you manage that? Because eventually you got past the royal we of you and added more members on, how did you centralize that communication?
Justin Kuryliw: Yeah, so right away I knew I needed more people to do this. First of all, I’m not a developer. I can look at code, but I’m not someone that can sit there all day and also build test classes. It’s not me. So I knew I needed someone that could help develop the app. I knew that I needed help with documentation for technical writing, and I also knew that I needed more people to help own specific features with the buildout.
Justin Kuryliw: So right away, I recruited three people on our team that eventually became co-leads with me on the project and they were our product owners for specific of the app. So delegation was extremely important given the timeframe we had. We only had two weeks to build out the application. So like I said, we had, for example, Claire on our team owned locations object, which is buildings and the like, we had one other person that owned just the lightning components and the development areas of the homepage for making sure that was built out.
Justin Kuryliw: And so everyone owned that piece and we collaborated everything back into a single working document. At Salesforce, we use Quip, that’s our preference, and everything in there included a project plan who owned what at every single point in time. We had a specific area for issues that were preventing them from going forward. In this document, we had feature descriptions, anything we had around messaging or checklists of things that we needed help on. Everything was in this working document and then we use that working document to discuss in our daily stand ups.
Justin Kuryliw: So we also put together daily stand ups where everyone on the team would come together and present on their section. Every other day, we actually had everyone demo their app of what they’ve worked on, because when you have four different people building the application, consistency starts to become very challenging. And so, things like labels, making sure our features are working with each other and that our visions are aligned. So every other day, we’d have a demo of what was new and what was built.
Gillian Bruce: Were you all building in the same exact environment or were you building in separate environments and then kind of bringing it together?
Justin Kuryliw: So early on, it was just a single environment. We found that after a while that needed to change, especially after we went live and needed to support the app. So we actually use Salesforce DX for spinning up scratch orgs, and the scratch orgs we develop each individual fix or feature within those apps, combined them together in another scratch org and then deploy those back to our org. So it’s a lot like a sandbox strategy. We just don’t have the option of sandboxes in our dev org.
Mike Gerholdt: So is the case. I think one of the things you mentioned early on, well, in your last answer, was, you know, I’m not a developer, I can’t sit and write Apex classes all day. I’m curious, how much of your solution involved code?
Justin Kuryliw: So early on, I would say in the first two or three days, we published design principles within the teams. So those design principles were little to no impact on production objects, making sure that it was user first, but the third one is less code. And we wanted to try and eliminate the amount of code as much as necessary because wanted, again, for this to be easy for people to understand when they installed it, and we also didn’t have a lot of time to be going through and troubleshooting code since we were on a two week schedule.
Justin Kuryliw: So we tried to keep everything within declarative click-based setup as possible by using really powerful functionality like Salesforce lightning flows, by using lightning pages to guide users, by using dashboards and reports as much as possible to display information in the ways that we wanted to.
Justin Kuryliw: So there really isn’t a lot of code in our app. We ended up with only four lightning components and not really a lot of Apex at all in there because it was really around the UI and usability of when we needed to use code.
Mike Gerholdt: Very cool.
Gillian Bruce: That’s awesome. So you’re all working together, you’re having these daily stand ups. You said you worked in a two week timeframe before you actually had this app ready to go. Can you talk to me a little bit about how you made that happen? Because I know you all had your normal day jobs too, right? Like developing this app, but you’re also a sales engineer at Salesforce, which is a pretty demanding job. And I think a lot of our admins might be in similar positions where they still have to keep the lights on, they still have to do their normal day to day job functions, but they also want to develop these great solutions. So how did you manage both of those competing priorities?
Justin Kuryliw: Yeah, I mean, in the very early stages when we built the app, it was only four people. And like you said, two weeks is not a long time when you consider like that was design, that was build, that was testing and that was deployment. So really, we only had about four to five days to actually build the app.
Justin Kuryliw: And the way that we did that was, like I said earlier, delegation was extremely important, and constant communication. So our working doc, I mean, we lived in that working Quip document where we would go back and see whatever other people were working on and what was needed from others. We also found the daily stand ups to be incredibly important for constant communication around this.
Justin Kuryliw: And honestly, the platform lends to itself here. Like it really allowed us to build this because after we decided what we wanted to do, building out the object model in Salesforce isn’t a lot of work. Building a flow in Salesforce really isn’t a lot of work for what you get. So we were able to do a lot in a really small amount of time, especially after delegating it across four different people.
Justin Kuryliw: I would also say that it really helped us in the beginning phase to spend two days of our one week of building just around planning. So we, we got a lot of value out of making sure that we all agreed on the data model, we all agreed on what was in scope and what was out of scope. And we finally put hands to keyboard, no one had any questions about what needed to be built. Everyone knew, going into that day three of that first week, what they needed to go do and what the timeline was.
Mike Gerholdt: That’s pretty big. I mean, if you consider you had two weeks and you spent two days on planning, I think that’s a huge point. I did not expect you to say that. I was going to ask you, you know, heading out of this and now you’ve launched it and you’ve got support, looking back, if you were to offer admins any advice or anything that you feel you really nailed throughout the whole part of it, what would they take away from that, from you?
Justin Kuryliw: I would categorize it to three things. So one is recruit a team and figure out quickly what you can delegate. When you’re building an application, it’s always going to be better if you have other people to give you feedback to help you come up with ideas, to help you validate those ideas and also just to build it out in the timeframe you have.
Justin Kuryliw: The second would be planning. Make sure that you spend the appropriate amount of time upfront knowing what you’re going to do, documenting it so that you can refer to it later. Because we constantly referred to our built out data model chart and our feature descriptions, so on and so forth.
Justin Kuryliw: And then the third would just be constant communication. Figure out a way that works for the team to communicate, figure out what it is that you need to communicate and then do it really well. My motto for this project was over communicate and I think that really helped us.
Gillian Bruce: I think that over communication is a theme that we have seen across every successful admin across every successful project. And I think beating it into our minds that there’s no such thing as over communication, I think it’s an oxymoron, right? You got to communicate and if you’re doing it well, there’s no such thing as doing too much of it because then everyone knows what’s going on. So I think that’s a really important point.
Mike Gerholdt: Gillian, I like the fact that we’re reminding admins to communicate on a very communicative podcast.
Gillian Bruce: Hey, got to communicate all the things all the time, right?
Mike Gerholdt: That’s the shirt. Communicate all the things. Love it. Justin, I want to make sure you have an opportunity to give a shout out. I know it was more than just you that worked on this, but for the team members that helped you, give their 15 minutes of fame on the podcast.
Justin Kuryliw: Yeah, absolutely. Like I said, this was absolutely a team effort and our co-leads on the projects were [inaudible] who helped us a lot with the development testing and the deployment of the application, Claire Palton, who is our go to market lead and also ran the locations and objects, and Shelby Crane who did a lot of the testing and demo build for us and also owned a couple of objects herself.
Justin Kuryliw: So one of the things actually we’re really proud of is that the team was mostly women besides me. I kind of ruined it, but they did a great job co-leading it with us and with me and I’m really proud to have them as teammates.
Gillian Bruce: That’s great. I mean, it’s amazing what you have all created and I think it’s a really cool app. It’s going to help a lot of people and a lot of companies right now. I think it’s also a great inspiration for all admins who are thinking of new ways to kind of solve these problems that are either arising or have been sitting there for a while and that they’re now seeing in the organizations, maybe their organizations are using Salesforce more or leaning on the technology more, or maybe it’s just an opportunity to really kind of dig in and get some stuff going. So I think that this is a great story. I really appreciate you sharing it and I so appreciate the time and effort that you and the team put together to make such a cool thing. So thank you.
Justin Kuryliw: Thanks for having me.
Mike Gerholdt: So it was great talking with Justin and these are three things that Gillian and I learned in our discussion. Gillian, why don’t you kick it off?
Gillian Bruce: Well, the first thing that I really liked that Justin talked about was the idea of recruiting a team and delegating. Now, Justin is a sales engineer at Salesforce. He has a wealth of very smart people he works with to tap into for this, although they were all still doing their day jobs. But I think even if you’re a solo admin, there’s something to take from that, because if you are working with your users, you have to recruit a super user, you may have a mentor in the community, it’s still really important to recruit people [inaudible] help you and kind of view that as your team to build and develop and deploy.
Mike Gerholdt: I would agree. The second thing I learned was planning is so important. I was literally almost floored when Justin said that he took two days for the whole team to plan out what they were building. And as Justin said, he goes, “That way when we put fingers on keyboard, everybody knew without a question what we were building, why we were building it and where we were headed with it.” So I love the idea of planning. I think sometimes building an app is like making the movie, if you plan everything in advance, then the building goes very [inaudible 00:20:25].
Gillian Bruce: I like that. Now I want to go watch a movie.
Mike Gerholdt: Sure.
Gillian Bruce: So the last thing, and kind of the third point that I think both of us got relate very clearly communicated to us from Justin was about clear communication and the idea of over communication, which I beg to say is not necessary because if you’re communicating enough, there’s no such thing as doing it too much. You know, you got to continuously talk to the people that you’re working with and building and developing, as well as your users, and getting feedback about if this works, if this doesn’t work, and having those daily stand ups that he had with his team to make sure everything is going as planned and what’s happening and where are we at. So communicate, communicate, communicate.
Mike Gerholdt: Gillian, would you say communicate?
Gillian Bruce: I would, I would say communicate.
Mike Gerholdt: Hey, let’s communicate Justin’s Twitter handle so that everybody that listens to the podcast can follow him.
Gillian Bruce: Yeah, Justin on Twitter is pretty easy to find. You just have to know how to spell his last name. He’s @JustinKuryliw. Now that’s K-U-R-Y-L-I-W. You’ll be able to find him. Links in the show notes. There you go.
Mike Gerholdt: No problem. And speaking of the show notes, if you want to learn more about all things Salesforce admin, go to admin.salesforce.com to find more resources. And as a reminder, if you love what you hear, be sure to pop on over to iTunes and give us a review. I promise we read them all and we’ll tweet the really good ones.
Mike Gerholdt: Now you can stay up to date with us on social for all things admins. We are @SalesforceAdmins [inaudible] Twitter. You can find me on Twitter @MikeGerholdt, and of course Gillian @GillianKBruce. So with that, stay tuned for the next episode and we’ll see you in the cloud.
Today on the Salesforce Admins Podcast, we talk to Andrew Russo, Salesforce Architect at BACA Systems. Join us as we chat about Salesforce Foundations and why it’s a game changer for solo admins and small orgs. You should subscribe for the full episode, but here are a few takeaways from our conversation with Andrew Russo. […]
Today on the Salesforce Admins Podcast, we talk to Eddie Cliff, VP of Product Management at Salesforce. Join us as we chat about Salesforce Foundations and how it can give you access to even more capabilities within Sales, Service, and beyond. You should subscribe for the full episode, but here are a few takeaways from […]
Today on the Salesforce Admins Podcast, we talk to Lisa Tulchin, Senior Curriculum Developer at Salesforce. Join us as we chat about user learning styles and how to use them to create better training sessions. You should subscribe for the full episode, but here are a few takeaways from our conversation with Lisa Tulchin. Choose […]
