What would you teach to a team who knows little about Engineering and what's needed to create a product/service from scratch in Engineering? I was recently hired for an early-stage startup and want to help the founding team see the real scope of what we will be facing.
Sort By:
Oldest
CTO in Softwarea year ago
This question can actually have an extremely wide scope. However, coming from my experience of building software products over the last decade or more, here are a few key starters:1. Understand what the product must do FOR THE USER.
This critical aspect is so easy to state but so difficult to adhere to - at least consistently. What is the take away for the user from this product? In the process of understanding - separate the capabilities from the domain specific use. For example, if building an analytic product - irrespective of the domain, understand whether it is time series analytics that the user needs or pure statistical analysis. The need for building metrics to generate trends is very different from the latter - which needs more of data cleansing, accumulation and querying at scale. This is just one tiny aspect. Spend entire days in front of the dashboard to answer with clarity - if I am the user, what will I take out of this product, and how would I prefer to take that out - download? mobile screen? desktop? Whatsapp message?...
2. Understand the context of the use.
Is it an enterprise product or an individual consumer focused product? This context is a key driver the product - system architecture. Whoever builds the product needs to understand the contextual details. Even within the enterprise - there could be further detailing like is it only a departmental use or does it have usage at the edge (branch / sales partner) etc. Finally - usage volume and patterns (when is it going to be used) is another key contextual attribute
3. Understand the legal context.
Rarely will a product not capture and / or use data. Data brings its own geo-contextual constraints. Critical to establish the context clearly and accurately at the start - because this - like the usage context - is a key driver of the product deployment architecture
4. Create a minimum viable product outline and a roadmap
Software Engineering exists to deliver the needs of the product. There is always some way to achieve even the most outlandish of dreams. However, such efforts obviously come with time and cost considerations - so establishing a viable path to the complete product capabilities is essential
5. Explore engineering options
Explore no-code / low-code platforms if coding is not a strength. However, if that is not an option, invest in at least two great UI / Frontend developer and two great backend developer. The rest can grow as and when required and can develop around them. Outsourced partners are an option to be used after due consideration. IP rights, client privacy requirements and code control can be major hindrances.
Chief Technology Officer in Softwarea year ago
Start building small components. Once the Team is familiar with concepts, work on bigger items. Build in agile manner ,code , fail and deploy againSenior Director Engineering in Travel and Hospitalitya year ago
Take the user centric design approach for the application design.Take the value driven approach to convince the team on functionality
Eventually a agile process of doing things small but constantly deriving value is the best way forward
Chief Technology Officer in Softwarea year ago
We work with startups day in day out. There are the usual suspects, iterate quickly, build MVP etc. The one thing i would teach any team is avoid the deadly "It just needs a" loop. This is that terrible scope creep that comes in where non engineering people get close to launch and keep adding new features in this endless cycle of " we just need this to launch". Of course you need a good product but let the users dictate what they need and what they do not. Otherwise... have fun and enjoy the process!!!
- If the team knows little about Engineering, hire someone who knows more about Engineering. If tech is core to your product, don't treat Engineering as a second-class citizen.