Building Software for Non-Technical Clients
Tips for effectively turning client ideas into working code.
As a Product Manager at Crowdbotics, much of my day is spent translating a client’s feature ideas into high-quality software products — making sure everything is built on time and within budget, and making sure delivered product exceeds a customer’s expectations. Building products for clients is different than building for yourself, because you inevitably have the added pressure of account management.
An account manager represents an organization and is responsible for the management of a relationship. A product manager is responsible for the strategy, roadmap, and implementation of product features. When you build software products for non-technical clients, as I often do, these two roles blend in ways that can be challenging for some people.
This article provides my advice for product managers who operate in user-facing roles in merging both responsibilities, especially those that build software for non-technical clients and stakeholders – whether those are inside or outside an organization.
Unlike technical clients, non-technical clients don’t necessarily understand the ins and outs of how a product is being built. Not only do you have to make sure that the right product is being built at a given time, but you must also explain to clients in natural language why you are making the technical choices you are making.
Below are five things that I have found helpful in building products for clients.
1. Use Constraints
Every product needs to have its boundaries. For the most part, your clients come to the table with defined boundaries: budget, timeline, features, etc.
Keeping those boundaries in check, however, can be tricky. Building just one more feature request can be enticing and non-technical clients are not particularly aware of technical debt on a feature-by-feature basis.
Being comfortable with hard conversations is the key here. Some non-technical clients, upon seeing the early stages of a product that just a couple of weeks ago was merely in their imagination, start to expect more.
If you don’t put constraints on releases, you will end up with nothing built. Deviating from original release requirements to accommodate small tweaks open the door for ten more. Even if it requires some backtracking, I have found it valuable to first satisfy original release requirements, then accommodate feature changes after release. It’s not always feasible, but this should be the expectation you set.
You don’t have to rigidly decline every client request but you need to identify what’s necessary and what’s a distraction to the product you are building.
Take away: Identify the parts of the product the client needs the most. Start with a tight scope around the top 2–3 requirements. A client might instinctively push you towards other small details. Listen, but don’t deviate from the plan unless you know with the detail she is asking for is critical for release. Release, then refine.
2. Be THE user
How do you know if a feature is essential or a distraction? Use the product.
Don’t just be any user; be THE user — the target audience.
A good product manager, according to Ben Horowitz, operates from a position of confidence. You won’t have that confidence unless you are the most rigorous user of the product. It’s easy to look at Invision or Github and comfort yourself that you know what’s being built, but you won’t feel the product unless you use it.
This is paramount if the client is non-technical. Since they can’t comment on the code, their feedback will be centered around how they feel about the product.
Not only you need to be able to empathize what they are feeling.
Take away: Use the product every day, even if there is nothing new. Put yourself in the mind of the target user.
3. Don’t be a parent
This advice is especially important if your team is doing creative work. If you are constantly telling your team exactly what and how something needs to be built, then you are not allowing them to be creative.
Non-technical clients can also feel alienated in decisions about the technical stack. This is a natural cause of anxiety for them. Instead of telling them that your decision is in their interest and they need not know more, take the time to explain technical decisions to them in a language they understand.
For example, simply saying that, “we are using X stack because it will decrease the build time,” is not enough. Tell them why it matters to them. A more complete answer would be, “we are using X stack because it will decrease the build time. And from what I understand, getting to market is more important for you right now than building a perfect product.” Remember the ‘because.’
If you are making the right choices, chances are they are going to agree. If your take the time to explain technical choice, they will feel like they were the decision makers. When a client feels like a decision maker they are typically more please with successes and feel more invested in improving miscues.
Take away: Own the product, not parts of it. You won’t be able to build great product obsessing over all the bits and pieces. Enable the client to adequately define requirements from a creative and usability standpoint. Let the development team take ownership of individual parts.
4. Side with the Coder Subjectivity
A fundamental misunderstanding most people outside of tech is that ‘code is code.’ There can’t be two answers for the same question. The reality, however, is totally different.
Coding is highly subjective. One person’s take on the problem can be different from another, and just a valid. It often requires a lot of creative effort to write a piece of software. With the explosion of programming languages and available frameworks, creativity and subjectivity are more important than ever. Steve Jobs famously laid out this tension between the content and tech industries.
This misunderstanding, however, is not limited to Hollywood studios and record labels. Your job as a PM is to make sure that your client not only understands this. But appreciates it as well.
Take away: Talk about the human side of developers in your team every now and then.
5. Communicate. Communicate. Communicate.
Effective client communication is concise, empathetic, and occurs at regular intervals. As the old axiom goes, good communicators are effective listeners.
Communication is not crosstalk. If you and your client are talking past each other — which can happen — it’s time to take a step back.
Don’t get frustrated that the client does not understand certain aspects of their own product or has not thought everything through. Rejoice because your work just got whole a lot more important.
While non-technical clients might not be good at understanding the technical side of things, most people are still adept at understanding the logical flows of the application. You just need to find a different way to explain it.
When you hit an impasse, know what can be effectively communicated in the moment, and when to take a break.
Put yourself in your client’s shoes. Understand not just their product but the market in which they are operating, and you will have a fun time talking to them.
Take away: Have a preset daily standup time. Be flexible on the format, but make sure everyone shows up.
Conclusion
At the end of the day, effective product management when working with non-technical is about clearly defining requirements, sticking to the game plan, and effective communication throughout the process. If you can do that, the rest comes easy.
Have you worked as a product manager with non-technical clients? What lessons have you learned? I’d like to know.
Crowdbotics helps non-technical people turn ideas and specs into working software products
If you have a project where you need additional developer resources, drop us a line. Crowbotics can help you estimate build time for given product or feature, and provide specialized developers as you need them. (We also support technical teams too! Learn more here, or try our app builder.)
