An Efficient Engineering Process for Building Customer-First Software Products
As engineers take on more senior roles within an organization, their focus expands from execution to broader concerns like scalability, reusability, and extensibility. However, guidance on balancing these priorities while delivering a product on time is often unclear. This challenge is especially prevalent in resource-constrained startups or new teams at larger companies, where product ideas often come with significant ambiguity and constantly moving goal posts.
In these scenarios, product managers or business leaders may communicate a vision, but the technical roadmap to realize that vision is often very vague. Engineers are often expected to step into this gap, given their better understanding of the technical challenges involved, especially in the absence of a technical program manager (TPM).
Drawing from my experience building full stack solutions in both large enterprises and startups, I’m proposing a streamlined approach to product development below. I hope this can help ensure that the end product is not only robust and scalable but also easy for others to maintain and extend.
Sample Problem
To explain this, let's assume the product in question is a simple account management service, allowing users to register, log in, and manage their accounts. The product has a front-end component (sign-in and register buttons, form fields for email and password), a back-end authentication system, and a database for storing user credentials.
Step 1: Clarify Requirements
Once you are given a high-level problem statement, it's crucial to define and negotiate the scope of the project and set expectations.
In this stage, you should:
Collaborate with the product manager to identify the core use cases and features.
Identify how the product’s “success” will be measured.
Talk to stakeholders, UX designers and other resources you will be working up to establish relationships.
For the auth flow sample problem example, these might be some example questions to think about:
Step 2: Define and negotiate the scope of the initial release.
Before jumping into development, spend at least a week identifying all possible use cases and defining the release scope. The first release is crucial because it makes or breaks credibility of the engineer. In some cases, the product manager may not provide detailed technical requirements, so engineers must break down the scope and suggest a release that focuses on the most critical features.
The release should:
- Cover the core functionality of the product.
- Be flexible enough to extend for future use cases.
- Prioritize customer impact and scalability.
Step 3: Design the Technical Solution
The next step involves designing the architecture and systems required to build the product. This should take another week, during which you:
- Develop a technical design document that outlines the architecture, data models, API designs, risks, and mitigation strategies.
- Identify key stakeholders and define milestones to track progress.
- Include adoption metrics to measure the product’s success.
Here is a good template for technical design:
1. Defining the Problem
Glossary
Problem Statement
2. Requirements Analysis
User Stories / Functional Requirements
Functional Guardrails
Non-Functional Requirements
Out of Scope
Open Questions
UX / UI
3. Solution Overview
High-Level Solution
Alternatives Considered
4. System Design
System Design and Architecture
Technical Questionnaire
Technical Guardrails
Key Technical Decisions & Alternatives Considered
Risks & Dependencies
Security
5. Build, Test, and Release
Metrics
Milestones
Test Strategy
Launch Plan
Appendix
Step 4: Design Review and Feedback Loop
Once the technical design is complete, conduct a design review with the broader engineering team. This step allows you to receive valuable feedback from engineers who may have more experience or a different perspective. Depending on the complexity of the product, you may need additional iterations of the design review.
At this point, adjust the design based on feedback and finalize the scope. Only after the design review is approved should you begin building the product.
Step 5: Execution of design
Once the design is finalized, the next step is to prioritize development tasks. There are two schools of thought here:
1. Start with the data model and build APIs and back-end services around it. This approach works well for features where back-end complexity outweighs front-end design.
2. Alternatively, start with the front-end components, especially if the front-end experience is the primary focus of the product.
For this example (an account creation service), the back-end (authentication, user management, and database integration) is likely more complex, so it makes sense to start with the data model and back-end services.
Divide the development work into user stories and prioritize them based on the team's capacity. Always consider scalability, maintainability, and usefulness to the end customer when making decisions about the architecture and implementation.
Conclusion
Creating a scalable, high-quality product is a team effort that requires clear communication, well-defined processes, and collaboration across different roles. By following a structured approach, you can significantly improve the likelihood of building a product that meets both customer and business needs.
I would love to dig further into the execution in a seperate article if you found this useful. Please let me know in the comments. Also feel free to reach out if you have any suggestions or feedback on this process! I'd love to hear how other teams approach similar challenges.