Digital product agencies (DPAs) and other developers can help you build your app if you can’t or won’t do it yourself. Agencies are particularly valuable because of the wide range of professionals with different skills they have on hand and their depth of experience.
But what if you’ve never worked with developers before? The upside of a solid working relationship can be a reliable application that gets the job done for your users. But to make the most of this opportunity there are some key insights you need to know (or you risk losing time, money, and even your project’s viability).
Read on to learn how to work with your developers and, with a little luck, get your app built right the first time.
Do I need a programmer, developer, or engineer?
Many experienced business professionals who get into the tech sector for the first time as entrepreneurs or startup founders are unsure of some of the terminology, so there’s no shame in it.
As such, you may find yourself wondering “Do I need to hire a programmer, a developer, or an engineer? And are these even important differences in the first place?”
Unlike job titles most people are familiar with such as 'doctor', 'firefighter', or 'grocer', there's a surprising amount of ambiguity for most members of the public around what to call someone who writes code.
Short answer: they’re the same. Programmers, developers, and engineers are all people who write code. For most people, that’s enough. Some organizations have preferred terms for their developers, ‘or devs’, favoring one of these labels over the others.
However, if that’s not sufficient detail for you, Alan Skorkin has a great blog post in which he lays out the more nuanced, technical distinctions between the various kinds of coders.
Of course, rather than hiring individual developers, you may engage the services of a digital product agency (DPA) like Develocraft. If you’re not sure if you need to hire just one or two devs, if you’re looking for freelancers, or if a DPA is right for your situation, you can check out our post on finding developers to work with: How to find an app developer.
Once you’ve found the developer (or developers) for you, it’s time to consider how best to work with them effectively, which brings us onto our next section.
Understanding how engineers think
Software developers and engineers are people too. That said, many developers share a core set of personality traits that can influence how they interact with others in the workplace.
Your archetypal software engineer / dev is extremely analytical and comfortable thinking about solutions to complex technical problems. However, this tendency to focus on a narrowly defined problem or task can sometimes lead to a loss of broader perspective.
As with many professions, programming tends to attract people with certain kinds of personality. It's not a hard rule by any means, but it's worth taking into account.
As any competent project manager knows, each distinct task is but one link in the chain (or several chains) leading to a desired final outcome. As the owner, CEO, or other responsible person at your startup, that outcome is not simply an elegantly written piece of software that fits with the potentially idiosyncratic coding preferences of your devs. It’s a successful business that succeeds in part because of a piece of software.
Within the development process, it’s your role to be an advocate for the interests of your business. While individual developers may be highly skilled at what they do, they’re usually not project managers or executives taking a broader view of the context of their software.
This leads us onto our next point:
Be clear at all times
Developers often regard themselves as problem solvers. What problems do they solve? Finding creative solutions through their mastery of programming languages to bring about the results specified by their clients.
As with all complex projects, if the objectives and preferred methods are not made explicit in the briefing, it’s possible or even likely that a gap between the unexpressed expectations of the client and the software delivered will emerge.
This can be particularly dangerous to a young startup or one short on funds, which may not have sufficient funding to make changes after the mistake has been made, leading to the failure of the venture with no path to raising revenue with an incomplete or incorrect product.
Even for well financed startups, there can be significant costs associated with unclear or poorly defined expectations. While the money may be on hand to correct the mistakes, no cash-rich investor can buy back wasted time.
The consequences of delays can be extremely harmful and, crucially, irreversible. In the tech industry, being the first to release an innovative digital product is often the best way to ensure long-term success.
In a world where capturing market share is the main priority and - particularly in some circles - investor cash is readily available, the temptation can be to ‘move fast and break things’, as per the mantra of Facebook.
Being the first company to release a particular kind of novel technological solution that catches on can lead to the public identifying every subsequent version of that solution with your own product. Emerging competitors may struggle to be seen as anything other than second best and imitations of your product, even if their product is superior in certain areas.
Time may be of the essence, which is why you want to get every step in the process right the first time whenever possible. That means making sure all your key assumptions and expectations are properly communicated.
Consider the ingrained habit of using Google as the default search engine of choice for much of the western world - though there are other markets with distinctive characteristics such as China where this is not the case. Google’s early dominance in market share has proven remarkably challenging for competitors, even remarkably well-heeled ones, to challenge.
However, it’s worth remembering that when companies such as Google or Facebook launched they were able to grow their market share rapidly in part because they had a product that satisfied their user base and connected well with their market.
While speed can mean ‘being first’ at the expense of your competitors, if the perceived urgency of getting a product out fast means that care isn’t taken at every stage, your competitors will thank you for actually slowing down your development process by introducing so many flaws that you have to delay your launch.
As such, excessive speed can lead to lack of care in documenting the exact requirements of your product to your developers, leading to delays and wasting the opportunity to capture market share early.
An experienced developer or digital product agency will request that you complete a product requirements document (PRD) that lays out all of your needs in detail, helping you to avoid confusion, get to market with a great product on time, and ultimately grow your business into a success on the back of your code.
To learn more about how to complete a PRD, you can check out out guide to the subject: The Product Requirements Document (PRD): How to decide what features your app needs.
So far, we’ve considered the importance of understanding how developers think and being clear about your expectations when working with them - but there’s one step you can take that will all but ensure that your goals are aligned with those of your developers.
Include developers in your planning process
No matter how good your PRD is, it’s a set of instructions on the preparation of a complex product requiring considerable technical expertise. As you spell out each additional technical requirement, you’re just as likely to raise more questions as you are to answer them.
The way many startups initially envision the process is to write the PRD document and then send it to the developers, who will then create the software described in the PRD. In such a scenario, it’s highly likely that the developers would come back with a multitude of technical questions which, depending on the technical knowledge of the people who prepared the document, may mean revisions are necessary.
Involving your devs in the planning process can bring potential stumbling blocks to light early on and help you address them early on.
This process can take extra time and effort which, as we’ve already pointed out, can bring its own disadvantages.
To avoid being slowed down by a stream of questions and potential obstacles, involve developers in the planning process as early as you can. Regardless of the type of project you’re running, having the developers who will be writing your code present at an early kickoff meeting can help them understand your needs, get questions and clarifications out of the way quickly, and help them understand what your intentions are.
Having this understanding of the context of their work and being able to question the various aspects of the project also gives your developers the opportunity to make helpful suggestions which may ultimately improve the quality of your digital product and accelerate development.
This means you can start capturing market share sooner and more effectively.
But what about the actual management of the development project itself? How will you interact with the development team and how will tasks be organized? That’s the subject of our next section.
The development process
In an ideal situation, each member of a development team has a well defined role. Each role is generally situated within a sub-team, such as quality assurance (QA), product, and engineering.
And in most digital product agencies, the teams will carry out their work within a project management framework, like the Agile Scrum process. This framework is used to manage the performance of tasks and monitor progress while keeping the overall project on track despite the inevitable roadblocks that will emerge in most development cycles.
Here’s a quick primer on the role of each type of team member within the flow of this framework.
In the first stage of this (idealized) process, project managers take the lead:
Stage 1: project (or sometimes ‘product’) managers:
- Oversee ideation in problem solving and manage the backlog of unperformed tasks
- Work with developers to decide which tasks to prioritize and schedule their completion within short work cycles known as sprints
- Assigns tickets in the project management system to developers
Stage 2: developers and QA pros attempt to complete their assigned tasks:
- Developers work through their tasks, regularly reporting progress daily to either their project manager or engineering lead, receiving feedback as they progress
- Engineers work with QA to ensure that each feature is fully tested before being rolled out
Stage 3: all parties cycle back to review and regroup before the next development cycle begins
- All parties (project or product managers, developers, and the QA team) meet for a retrospective review of the previous stages, providing feedback. Information front these sessions is (or should be) used to improve planning and performance in the next sprint.
- If relevant, any changes made are delivered with new features launched or updates pushed out.
- Return to stage 1 for the next sprint.
Remember; this is an idealized version of the workflow. In emergency situations, the process may have to be sidestepped. It’s also worth noting that - particularly in small teams - the same person may have multiple roles. For example, a senior engineer might also serve as the project or product manager. They may also be involved in quality assurance.
Above all, the biggest piece of advice from this section when it comes to working with developers is to make sure everyone is clear on their role within the process (rather than simply assigning job titles).
Clear roles and clear processes lead to clear results. Don't neglect organizational arrangments.
The responsibilities of each individual should be as clear as possible and everyone should understand how each of their tasks fits into the wider project. To help with this:
- Clearly state roles, responsibilities, and outline the workflow in a document that all parties have access to and can refer back to during the process.
- Respect the chain of command. If you’re the client or ‘product owner’ and you’ve been assigned a contact to liaise with as your point-person for raising concerns, offering feedback, and so forth, make sure you don’t circumvent them. Doing so will confuse team members and ruffle feathers.
- Make sure you have eyes on the project’s progress. Don’t wait for your project manager to report that things are wildly off track before taking an interest. If you see what’s happening, you’ll catch on if your team isn’t up to the job. Alternatively, if things are going well, you can report back to investors or other important stakeholders, which can be a useful source of reassurance.
Ready to get started with your own development project? Develocraft is a digital project agency with a range of professionals that can help you out at every stage of the process, from ideation to verifying the quality of your existing code and testing.
Hello! I'm the head of content at Develocraft. I'm also a startup guy (no joke)! I've worked with a lot of them and learned so much. I'm here to help you by sharing that knowledge. I'm always open to collaborations. Find me on LinkedIn.