Many business owners and founders from non-tech backgrounds often don’t spend much time and effort explaining the business context to the requirement. Putting effort into giving business context and aligning the tech team members with purpose, missions, and vision is a long-term investment and the first step in building a high-performing tech product team.
When you spend most of your time with computers, you become good at communicating with them, but your skills of communicating with people go for a toss, and that’s what happens with most software developers.
Translating business ideas into technical requirements for these developers is one of the biggest challenges for founders and business owners with a non-tech background. When the business idea, vision, and mission are not successfully translated into technical requirements, it leads to the development of the wrong product, delayed execution, higher costs, and a final product that falls far short of the customer’s expectations.
The core principle here, like in any other successful team, is to lead with compassion, empathy, and patience.
Make your technical team members understand the business context, the mission, and the core business problems that need to be achieved.
Business owners and founders often don’t give team members the proper context of why we are doing what we are doing, and if we do not solve this problem, what will be the impact? We assume tech people do not know these details, or sharing them might lead to them stealing your tech idea. And that’s where we take our first step wrong.
You have to speak at the level of tech team members and explain why we are doing what we are doing in straightforward terms without using management jargon.
Role of a Product Manager in bridging the gap between non-tech clients and developers
The product manager(PM) ‘s role is critical when communicating with the developer. A good PM has the right mix of commercial, UI/UX, technical, and customer sense.
The PM’s job is to validate, prioritize, and document the business requirements so that tech developers can easily understand them and convert them into code. A good PM is someone who has been in a technical role previously and has been in the PM role for at least three years.
Steps, Tools, and Techniques to Correctly Translate Business Needs to Tech Specifications
Founders and businesses often spend a lot of dollars building the product. But often, the MVP developed fails to enable the customer to get value from the product, leading to failure in realizing the revenue. Further, in today’s world, where hundreds of products and tools are available in each category, developing a just-good enough product will not help.
When you are in such a situation, most of the time, the core reason is that you have yet to spend time validating the problems before developing the MVP, or you failed to translate those problems into a solution that led to building a minimum remarkable product.
Other reasons include developing something that is way too complex or has too many features, which leads to users not adopting the product entirely.
The ideal steps that lead to the development of a genuine minimum remarkable product that the customers love to use and pay for include:
- Market research and demand validation
- Competition research
- Talking to 10 to 50 customers to understand and validate the problems
- Craft & refine your business model
- Define the user journey maps for the critical workflows
- Creating the product design blueprint using mockups and UI design
- Optimizing the design for UI/UX
- Validating the business model
- Create the MVP roadmap and choose the release cycle
- Draft the user stories as per MVP roadmap and release cycle plan
- Developing the MVP
Steps 4 to 9 are iterative and take anywhere from nine to thirty-six months to reach a stage where your tech product is aligned with the repeatable, scalable tech product.
Leveraging mockups, wireframes, flow charts, and user stories
Mockups, wireframes, flow charts, and user stories are a few of the tools used in product companies by product managers, UI/UX designers & developers to clarify what needs to be developed.
- Mockups & wireframes are the visual representation of the product that should be developed. While a mockup is a visual representation, a wireframe goes one level further and showcases how the various elements of the product interact. You can use Pencil, Balsamiq, and Figma to create mockups and wireframes.
- Flowcharts represent the flow of the process and can act as input to help the developer understand how to code the system. The product manager created the flow chart, which can be documented as part of user stories.
- User stories document how a product feature will work after the system is developed. Though there is no specific format for user stories, I have seen that including the following elements in the user story document has worked better over the years.
- What is the business context, and why are we solving this problem? What will be the impact on the business when this feature is developed?
- Which user personas will be impacted when this feature is developed?
- Which existing workflows will be impacted after this feature is developed?
- Links to the mockup and wireframe of the feature
- How will the system behave once this feature is developed?
When developing the product, doing a below-average job in mockups, wireframes, and user stories will lead to below-average output from the developer. While you should not try to achieve perfection here, providing the above artifacts before the developer develops the feature will significantly help.
Achieving success in collaborating with developers
Choosing the right development team
The first step towards successful communication is hiring the right developer according to the required skills, experience, and expertise. When hiring a developer in your region or country, hiring based on these three parameters is enough.
Hiring a developer with the right skill set is necessary, and investing time in understanding the culture will enable you to develop a long-term relationship and trust, which will in-tunr improve the quality of the outcome.
Establishing a good process & system of product management
When developing a tech product, deploying an exemplary but not too complex product management process and a good product management tool is necessary. This will reduce anxiety about what needs to be done next, in the future, and what has already been done. It will help you and your tech product development team be on the same page and set the base for weekly and daily cadence.
Regular meetings and feedback loops
Establishing a regular meeting with the tech developer and you is essential. When starting the work, schedule a bi-weekly demo session on the features developed, which can later be shifted to monthly. The product manager and tech developer(s) should meet thrice a week to discuss the status and roadblocks.
Avoiding Common Pitfalls
Here are the common challenges and mistakes when translating a business problem into technical specifications used to build and scale the product.
Balancing over-specification and under-specification
The specifications given to the developers by the founder or product managers often lack required depth and breadth(read it as garbage in), leading to garbage out. And many times, you spend way more time drafting the specs, leading to a delay in the development. The balance can be achieved by setting the specific format for the specification that works for your team and your product.
Handling changes in requirements
Changes in the requirements are inevitable during the development of the product, whether you are in a 0 to 1 journey or a 1 to 10 journey of building your product. The best way to manage these changes is to ensure the process of drafting and reviewing the specifications is there in place. And to set the expectations within your team that sometimes it’s okay to have changes in the specification, as many variables are not in your control that lead to changes.
Simplifying technical jargon
Note down all the technical jargon your tech team uses. Google it and try to understand what it means. At the same time, set a principle in the company that no one will use jargon, neither at the management level nor in technical teams.
Leveraging collaborative tools for better requirement documentation
Draft the user stories and PRD using tools like Microsoft Docs, Google Docs, Jira Confluence, or Notion. And the reviewer of the specs can add comments in the same document while reviewing it. The Collaborative tools work well when the tech team is located remotely.
Training resources for non-tech clients
Here are a few resources that will help you to understand the world of technology.
Basics of technology
- Learn what is frontend coding frameworks,
- Backend coding frameworks
- Basics of how the software gets hosted on the cloud
- Technical skills required in a product engineer
How to Scale an App to 10 Million Users –
https://newsletter.systemdesign.one/p/aws-scale
FAQ’s
How detailed should technical requirements be?
It has to be a balance between too few and too many details. Define the format of the technical specification(called as user stories). Here is a sample format that I have used over the users
- Context: Why are we building this feature/idea?
- Which personas will be impacted?
- Which existing workflows will be impacted?
- How will the system behave after this feature is developed?
- Risk: What risks are there i.e What can go wrong once this feature is developed?
Make sure you answer these questions every time in every user story, and the developer reads through them before they start the development.
Who should be involved in the process of translating business requirements?
In a small tech product team, the product manager should document the requirements and specifications (aka user stories), and the product owner should review it. Once reviewed and updated, the developer should be briefed about the product specification.
How do you ensure the technical requirements fully capture the specific business feature idea?
Make sure that the format is defined and followed every time in each user story, the business owner reviews it, and the developer gets a brief before the development starts. Developer feedback should also be incorporated after the briefing session.
During development, if the tech developer discovers that the feature is not technically feasible, the feedback should be sent to the product manager as soon as possible.
What are the different types of requirements documents?
When building and scaling products, PRDs, user stories, technical architecture diagrams, and technical solution documents are produced.
How do you gather product functional & technical requirements?
Step 1.Set up a system to collect all the feature ideas from everyone. The system can be Excel or a tool like Jira Discovery or Aha.io. Whenever people add an idea, ensure they align it with the goal or core problem statement and the priority and give context as to why we should develop it.
Step 2. In each product release cycle, pick the idea based on priority and impact on the goals and problem statements.
Step 3. To gather more details of the requirement and to gain depth on the feature idea, discuss it with the team member who submitted the idea and with the customer, if required.
Step 4. Share the finalized item with all the people on the team concerned before the release starts.
