As we continue to move forward discussion object-oriented programming in WordPress, it’s important that we make sure we’re not jumping ahead of ourselves when it comes to building a product for someone else.

So often, it’s easy to:

  1. hear what a customer says,
  2. build something out based on what we’ve heard,
  3. turn it over to said customer.

But there is so much more to it than that. I’ve danced around it a bit in previous posts in this series; however, I want to start drilling down into what it means to hear:

  1. What a customer says,
  2. Develop a set of requirements,
  3. And then create feedback loops around that.

Ultimately, we want to make sure the people for whom we’re working the and solutions that we’re building truly are solutions and not hindrances or hurdles over which they have to jump.

Furthermore, I don’t think it’s enough that a customer simply enjoys the experience of their final product, but with working with the one (or the ones) building the solution, as well.

With that said, let’s take a look at what it means to listen what they say and go from there.

[restrict paid=”true”]

Understanding Customer Expectations

Whenever you read books or other material around this kind of stuff, it often makes one of two of the parties the “bad guy.” Not always, but sometimes it makes:

  • the customer seems ignorant as to what they are talking about,
  • or it makes the developer seem like a jerk for acting like someone who knows more about the topic at hand.

What about a third option where the customer has a clear idea of what they want, the developer(s) are willing to listen and work in conjunction with the customer to build something?

Sure, there is going to be clarification along the way, and there will be terms that have to be defined, and some “recalibration” of the development calendar may even be part of it.

But the bottom line is this: Neither party should be working against the other. Instead, it’s all about working together for the solution. Sure, it requires communication (which developers aren’t always great at, in my experience, but there’s no reason why it can’t be better).

What’s a Customer Saying? (What’s The Developer Saying?)

Whenever the two of you meet, you’re likely thinking the same thing because you each speak a different language and each of you thinks what the other saying is jargon.

And that’s not wrong.

Customers have a way of talking about what they want, and developers have a way of talking about how they’ll deliver.

The Terms We Use

But there can be a common goal.

Aim for a description of the problem that’s trying to be solved. Try to do so in laymen’s terms so that the design lines up with the goal and and functionality of the solution.

I don’t think if this will work for everyone, but this is the first thing I recommend doing whenever you’re sitting down with your client.

As you’ll see later in these posts, it helps to develop a few sentences that you can use at the outset of your statement of work to which you can refer back each time you have a decision to make.

In other words, you (and they) can ask:

Is what I’m working on contributing to the common goal?

And this is where you can determine the core set of requirements.

“It Needs To…”

When it comes to buying something, building something, requesting something, wanting something, or whatever, it’s pretty easy to start off the sentence saying “I want it to…”

But there’s a big difference between “I want it do [do something]” and “I need it [to do something],” and when you’re working in software, it’s generally safe to say that the things that are needed are core to the application. And the things that are wanted are what comes after the foundation of the application have been built.

That is, it’s a conversation about “must-have” and “want-to-have.” And it’s important to have conversations so that you can get to that final statement of the common goal of the application.

Once that’s in place, you’re able to begin then planning your software around the customer’s problem. And that’s where requirements gathering comes into play.

Developing Requirements

What you and the customer have a solid understanding of what needs to be built, then it’s time to put together requirements.

This part can be more fun than it sounds. I know, I know: It sounds like homework or some assignment, right? But it’s not. Instead, it’s taking what they want, what you’ve understood, translating it to a common language, and then writing up a document that explains what the software will do.

Depending on your experience, though, this can be boring. And by boring, I mean one of the worst parts of your job. Besides, requirements always change, right?

Not always.

If you take time to understand what they want from the beginning, then the requirements don’t have to be a 50-page document outlining how every single module has to work.

Plenty of books document it as saying that this how it has to be. But in nearly a decade of doing this, I’ve never had something span that long and customers have generally been incredibly grateful to see a short list that can be amended via email or Google Docs, signed, and then referred to as the project moves forward.

I’ll talk more about that in the future, but whatever bad experience you have, you fear, or trepidation you have doesn’t have to sit. And we’ll continue to talk about that through this series.

[/restrict]