Story: Deciding What to Build

[00:00:00]
>> Francesca Sadikin: So in our last story, we explored how building relationships of trust with the people we work with can open up more opportunities and accelerate career growth. But I found that trust isn't just key to creating opportunities, it's also super important for executing effectively once those opportunities come your way.

[00:00:20]
Okay, I've learned that the same soft skills, empathy, active listening and genuine care for others not only help build these relationships, but also makes you more effective engineers. So I'm gonna share how I learned this in two different experiences in my career. So, this mental trap that I show you on the slide, good solutions speak for themselves.

[00:00:47]
I feel like this is a very common mental trap that engineers fall into essentially getting so caught up in the technical aspects of a project that we lose sight of its real purpose. And this trap can happen In both personal and corporate projects where even with significant time like resources like many, many, many engineers.

[00:01:08]
And tons of money invested the final product may end up unused because it doesn't solve the actual problem. The reason is it's a shallow understanding of what users truly need. So I learned this lesson the hard way early in my career. I was part of a project where our team was tasked with building a series of tools for admins to manage their educational program.

[00:01:36]
In particular, one of the tools I was most excited about would solve how admins, for spending hours manually sorting students into groups using Excel. And I designed this really cool [LAUGH] solution that even now I still think is so cool. It looks exactly like this, it's a drag and drop system, and I implemented it perfectly.

[00:01:57]
It looked perfect but When I launched this tool, I realized a huge mistake for context. I have a background in design. I've spent many years thinking about users, but in all of my excitement in building this tool, I completely overlooked the basics of involving the actual users, the admins And the students while I was building this.

[00:02:24]
So we made assumptions based on what we thought was needed. We just heard you need a portal and a dashboard and a tool to help you sort it right? Cool, we'll build that. That's literally the type of conversation [LAUGH] we had. We did not check back in, and as a result.

[00:02:40]
When it was time to launch, our results reflected our approach, which is no one used it, the only users were us. And this project, which was meant to serve admins and students, failed essentially because we didn't bother to actually understand them. This experience was a really painful lesson, because we spent nine months building all of this with nothing to show for it.

[00:03:07]
So it showed me that building technically excellent solutions is only half the battle. Really, the most important part is actually understanding who you're building for and what do they need. This is where so many engineers go wrong, pushing out technically impressive work that doesn't solve anyone's problems. I'll pause here, what do you guys think?

[00:03:33]
Do you relate to it? Agree, disagree? Lot of head nods. Lot of head nods. We've all made this mistake. And sadly we still continue to make it in corporate settings too, [LAUGH].
>> Participant: So did you come up with a solution that users did use?
>> Francesca Sadikin: No, my time was done there.

[00:03:53]
[LAUGH] Was there another question? Go ahead.
>> Participant 2: As a consultant, I find that holds true for oftentimes people looking to create an initial idea like you have a start up idea.
>> Francesca Sadikin: Yes.
>> Participant 2: And they they wanna build it. And a part of me wants to just take the money and build it, and then another part, which is the authentic version of me.

[00:04:27]
During that first meeting, I always have to bring up these questions to see whether it's test users or user base in mind. And how these individuals who they're building it for, they've talked to them to see if this is actually a viable thing or not.
>> Francesca Sadikin: I think the authentic version of yourself would actually make you an even better consultant if you went that way, right?

[00:04:57]
But it does require a lot of the persuasion skills. Is of like first listening to their concerns and then being able to persuasively like lead them in a different direction that actually still solves what they're looking for, right? But yeah, I like kinda what you're saying is that sometimes I think engineers think they just are the coders.

[00:05:21]
But if we just code, we're then letting ourselves just be code monkeys, [LAUGH] right? So to really be a great partner, I think, with product owners and design, that is part of their role to be researching it. But I think we have a part in showing up as our technical experience in our roles, and just be, are you sure that's how you want to accomplish that.

[00:05:48]
Or you can be an equal voice to give your opinions, to see, is this really the direction that we want to go to? Because, I think, because we have the technical experience and we have to translate their requests into implementations. They're also lacking experience in knowing what's actually reasonable and what's possible.

[00:06:12]
And maybe there was a different way to achieve it. And so these are great opinions that we can offer to them as different solutions.
>> Participant 3: And sometimes, especially with startups, even if your gut or intuition is saying it's not gonna work, maybe an iteration of that idea will actually work.

[00:06:34]
So sometimes it's your responsibility to say, well, I'm gonna do the best I can with this. Put it out there and who knows? Maybe they know something about the customer or the audience that I don't. And suddenly that feature is actually used a ton. So in a way, you have to kind of balance both sides.

[00:06:54]
>> Francesca Sadikin: It's the agile way where, right, we just try to push out the minimum amount first, the one with the least amount of effort. Put it in front of real users and see what they actually say and then iterate, which I actually talk about in the next story.