Understanding The Full Customer Discovery Process with Alex Nordholm of DealWIP

Transcript

Ledge: Alex, thanks for joining us.

Alex: So happy to be joining you, Ledge. Good to be here.

Ledge: Awesome! If you don’t mind, give a two-, three-minute background of yourself and your work for the listeners before we jump in.

Alex: Sure, happy to do it! I am a lawyer by training. I did law school at UVA and then practised corporate transactional law for a few years at a couple of different firms here in New York City where I’m based.

About a year ago, I started talking to a couple of my best friends from law school who were also transactional attorneys about our experience as junior associates particularly about some of the workflow and administrative kind of low-value work pains we were having in transactional work.

We started putting our heads together as to how we could possibly solve that with software and really free lawyers up to do the more high-value work that they are really trained to do and that they’re, quite frankly, paid very well to do.

That was the genesis of the company. It started about a year ago and, since then, we’ve done a couple of product vision. We did an accelerator program with LexisNexis which is one of the biggest names in legal knowledge and information management.

And then, we did an awesome program this last summer with it called “MDR LAB” that was with a law firm in London and the U.K. called “Mishcon de Reya.”

And that was really about incubating and embedding with a bunch of their lawyers who would be our prospective users and talking them about their problems and really understanding deeply the pain points that they were experiencing and how we would attack them and also how our product might be into their existing workflow, systems, and tech infrastructure.

This summer when we were doing that program, we managed to recruit our internal development team which is in Nashville

. And our team includes a CTO and a couple of full-time engineers and also a product designer who are intimately involved in helping us formulate an MVP on the basis of understanding those customer problems that we’ve been discovering this summer.

So the idea is that we’ll be heading to market sometime early 2019 with our commercially viable products. That’s the quick story.

Ledge: So you did quite a bit of customer development there. I often wonder, what’s the right amount of that to do before you start dropping lines of code? Do you have that internal discussion on the way or was it a little more organic?

Alex: We had started building a concept with some outside shops actually prior to the program, and then pivoted pretty seriously during the LAB incubation program this summer to kind of a different product concept, not entirely, but really attacking a different problem in response to those user pains.

We were working to be deliberate but as things view it in kind of startup land, often, we found that there is really a more severe immediately pain and problem that we could be attacking than the one we were initially working so solve.

Unfortunately, we weren’t completely efficient in really holding off developing till we were committed to a particular vision. But it ended up being that we brought a team on internally and really pivoted our product vision at the same time.

So the team that we have now has been working on the current product basically since they started. It ended up being a nice parallel.

Ledge: You’re a product guy. You’ve been actually the type of user ─ the kind of startup where you set out to solve your own problem which is common. You’re a product guy. Now, you have engineers. You work with shops. You work with internal engineers.

What’s the best practice to get that stuff out of the mind of the customer and then to the engineering team so you kind of actually end up in the least wasteful way with what you want?

Just describe how you do the product engineering dance there.

Alex: We’ve spent a lot of time on working to both loop our team and on all of the kind of customers that we’ve been doing and then also design kind of a development process that brings everybody together in a code disciplinary way so that we’re on the same page when it comes time to actually build the features that we want to build.

I guess, on the customer discovery side, we did an extensive number of interviews and then surveys and then, finally, user testing during the course of the summer. And we’re quite deliberate about including our development team in on those discussions that we’re finding kind of real time.

Now that we’re really on a serious development cadence doing consistent sprints and things like that, we’re working to formulate a development process and, obviously, it’s never perfect.

But I think we’re getting to where we can take customer feedback. We’ve got a designer who is taking that feedback and designing features. And then, we’re bringing in our developers several weeks prior to building it and getting their feedback on the feature design as well as giving them the context from the user perspective on what this feature is going to mean for our users and kind of the “why” behind the feature which is really important for developers and then iterating upon our engineering feedbacks so that they can be part of the process; and we can design features from a technical standpoint that make sense and have implemented in a most efficient way possible.

And we’re doing that all before we build features. So we’ve really worked to create a collaborative process engineers in both from a design standpoint and, obviously, in terms of giving them feedback from the user so that they know why they’re building features.

Ledge: I love what you said that the engineers want to know why and that it’s valuable for you all to invest in telling, explaining, and experientially sort of having them involved in that process.

There used to be this idea that you could of just derive that all out of the product function and nobody needs to know why, just write me code. I think that’s a fallacy. It’s good that you came in that way and addressed the engineers as a meaningful smart contributing body to that process.

Alex: And they so are. Whenever we hold these meetings to talk about features and describe why we’re doing them and get their feedback, I’m always blown away by their suggestions. Even on a product level, I think it’s so important to be collaborative and kind of code disciplinary so that you can build the best product possible. I think bring engineers and involve their perspective in your future decisions.

Ledge: I ask a lot of CTOs this question and technology leadership, specifically, who actually do engineering recruiting as we do. It’s our interest to find the best ways to evaluate and grow engineering teams. We’re always interested in the methods of thinking and the heuristics around “How do you know when you have an outstanding A+ senior software engineer?”

From your perspective in a product seat, what are the heuristics you use to determine if someone on the engineering team was just an absolutely great hire that you want to keep around? On the flipside, what are some negative signs from a product viewpoint on an engineer who won’t make the cut for you?

Alex: Maybe the best way to approach this is just to tell you why I love our team and the really great traits that stand out about our team. Those are going to be the traits and things that I think we’re looking for going forward as we’re hiring people.

I love our team because, as I’ve talked about before, they’re really interested in digging into the why of features and understanding why we’re building certain features in our product and contributing to that process.

I guess, that’s one. And, two, it’s that attitude of collaboration and investment and not just building great products from a technical standpoint but building great products from a user standpoint and understanding why our users are going to really love this.

I love working with our team because they’re really motivated to help us solve our user problems at the end of the day. They understand that that’s kind of the ultimate goal of building something.

For a product guy, obviously, what stands out to me is just how invested they are in working to help our users solve their own problems.

Ledge: Just real quick, tell us about dealWIP. You are going to be launching this coming year so you’d want the audience to keep eyes on that and see if it’s a tool that their attorneys could use for their benefit.

Alex: We’re kind of a transaction of workflow and collaboration product. The initial product and the problem that we’re working to solve is ─ this might be a little esoteric but, frankly, it’s a big problem and that is in any transaction, there’s a process of due diligence.

But, basically, it’s a company that is buying; the target company needs to kick the tires, understand what liabilities there might be, what problems with contracts there might be. In tech transactions, it’s super important to understand the IP and make sure that the company has valid claims to all the IP and that the audience process ─ as many complex business processes are ─ is a highly collaborative process that involves dozens of people potentially on both sides of the transaction. As a result, it becomes a project management nightmare.

What we’re really doing is trying to bring kind of some of the more modern 21st-century approaches to project management and workflow into the due diligence fold because there aren’t any products out there right now that are working to manage the due diligence process in kind of a sophisticated project-management type of way.

So we’re working to solve that problem. I think we have an exciting solution and, again, we’ll be piloting this starting this February.

We’re very excited about it.

Ledge: And if every listener doesn’t care about that now, they will care about it when it’s saving them $500 dollars an hour down the road.

Alex: That’s right. Again, as are many of these processes, there’s a lot of time wasted by highly paid people kind of shuffling papers around. That’s what we’re working to solve. Let those people actually do $500-dollar-an-hour type of work.

Ledge: I hope they all go through so that they’re all getting their payout and, hopefully, using the tools.

Alex: Exactly!

Ledge: Alex, I appreciate your time. Good to have you on!

Alex: Absolutely! Thank a lot.