You, as a client of a design and development agency, are an integral part of the project team. Just as the developers are evaluated against their experience and skill level, there are categories that tell apart the good from the best clients.

Doing a good job as a client is not only a question of style points, but has a tangible effect on the main software project aspects: scope, budget, and timeline. By following the below points, you ensure that the project execution is smoother - in other words - that more design/software pops into existence for less cost.

This read will cover the key ways a client influences software design and development. You become a “good client” long before making contact with your first product partners - that is, in the idea phase. That is where the foundations are laid. Then, when onboarding your chosen product partners (e.g. design and development agency) communication is key. Namely, you’ll need to feed the product team requirements, accept the iterations and follow up with feedback.

Clear vision and mission

The first step is made long before the software product takes shape. The software that Cinnamon will build is one of the puzzle pieces of a bigger picture called the business model.

Excellent software cannot make up for a patchy business model. That is why a business plan needs to take shape before engaging a development partner. Once the project's main goal is carved out, a skilled product design team will have no issue turning it into a software concept.

"Product design is not business coaching. Those two shouldn't be mixed. (Software) product design can take place only after the business logic is known."

Imagine your idea is to offer quick-access, advisory medical service. The software that will provide it would be something that enables users to search through medical professionals, book sessions with them, and pay them via Google pay or Apple pay. That makes the software, but the business model must answer questions like: how do the medical professionals get onboarded to the service? What is the revenue model? Who is the target audience? When do we anticipate the break-even point? Etc. In this example, we see how the software is actually just one wheel in the works. As the business owner - you need to figure out the space around the software itself.

In other words - product design cannot answer what kind of business you need, but it will define the best software for a given business model. Sometimes clients kickstart the product design phase before having a business model defined. It happens. This is never a blocker, but it is far from ideal. Changes to the business model while the product design is taking shape will create unnecessary iteration cycles. This back and forth will lead to unnecessary costs and friction. That is why the best clients are those who come with a clear agenda and make us deal with the technical stuff.

Partnership mindset

The difference between a tech partnership and your regular development job hire lies mostly in the topics that are discussed between the parties. These topics can either be the abovementioned business concept or just strictly technical matters.

Bringing a partnership mindset to the project means that you’re happy with pitching the whole business idea to your dev team just like you’d do to stakeholders. The effect will be an engaging atmosphere on the project - the developers will be on board with your vision, not just code their days away. If the PM knows what the exact goal of a certain deadline is, then they’ll be able to adapt to the situation in the best way.

If all goes well, the project will grow in complexity in various ways (headcount, technologies, companies, budget, hierarchy...). As a business owner, you'll appreciate having a reliable core technical team. That is why treating your team as partners - not just as vendors - will pay off once the project takes off.

Communicating clearly

When working with a team that doesn't speak English natively, it is easy to fall under the impression that redundancy in communication is counterproductive. This assumption is wrong. An experienced project manager is able to filter out the key points from a conversation and turn them into action items for their team without creating confusion. Even though non-native speakers tend to fall behind in vocabulary when expressing themselves, they can still keep up with active listening.

Often times clients who are overly cautious in verbal communication will leave out information to avoid muddying the water. Once those clients get to know me and understand how I handle the information towards my team - they feel more at ease with communicating not only features/tasks, but also the bigger picture of the project.

Communication with your project team should be treated as a two-way street. Namely, if you hire a software agency, the squad working for you will come equipped with experience from past projects - that experience can be turned into suggestions that you as a client can take for the benefit of your project. The basis for constructive feedback is understanding the wider context of the project - so don't be afraid to pull your project team into that kind of conversation. The QA team is especially useful in this context because they always find scenarios that slip under the radar, but can cause complications later on. 

If all goes well, the project will grow in complexity in various ways (headcount, technologies, companies, budget, hierarchy...).

Be demanding, but fair

The client-agency relationship is a two-way street. Both sides will at some point be dependent on the other side. An easy-breezy approach from the client’s side should have no impact on the deliverable, but it can have an impact on the timeline. Why exactly this is the case you’ll read in the next paragraph.

Nondemanding clients are rarer than the opposite - clients with unrealistic expectations and unfair criteria. Usually, the clients’ approach is to eke out the last drop of value out of the project. This is a legit way of doing things as long as it is based on understanding the other side’s position. 

Regular feedback

The project scope needs to be defined clearly, there is no question about that. However, the reality of software development is such that changes happen during the project. Regular feedback is built into Cinnamon's design and development processes because we acknowledge the fact that a project concept evolves over time. Also, there is the fact that one's perception of software is skewed during the concept/design phase. What may look solid as an idea/mockup/demo can reveal unexpected twists once it is actually developed. This can be avoided with a User acceptance test (which Cinnamon always recommends) and by allowing space for corrective feedback. That is why we always invite clients to share their feedback regularly and early in the project.

A solid project team is always ready to handle change requests - it is up to the client to inform of any changes in scope and priority. Feedback can pose a blocker if the project is divided into milestone deliverables. This implies that timeliness is required when providing feedback.

It would be a shame if the project is prolonged due to the client side not taking the due time to affirm a design or feature.

Budget plan

Each project should be quoted in duration and cost. The project executor's part in budgeting is to make a clear projection of design and development costs so that you as a client can cover the project.

An open balance can become a blocker, especially when working with an agency. Namely, all the advantages that come with working with an agency (you don't need to worry about staffing complications, project management, testing, DevOps...) come at a cost. In order to offer all of those services, agencies target optimal utilization of the team members. If a certain project can not provide liquidity for covering the team, those talents need to be reallocated to a project which will ensure revenue.

Financing a business is rarely smooth sailing - that is why an open balance shouldn't be a show-stopper. However, if the project needs to meet a certain timeline, then the financial aspect should keep up.

(Nice to have) Tech savviness

The prioritization process tends to be smoother with clients who understand the technical implications of certain changes. Example: a new button on a web app potentially calls for changes on the API endpoint and in the database structure. For someone without technical sensitivity it may appear as "just a button, how hard can it be". Of course, when hiring a development agency, you're entitled to leave the technical details to the experts. A responsible dev team will adapt their reporting in such a way that technical pre-knowledge from the client's side is not in any way a blocker or hurdle. But it's nice to have.