Previous post: Let’s build Product, not Software - Part 1
In the first part of this series, I have walked you quickly through some differences between Building Product and Building Software and why Building Product is important. In this post, I’ll show you a simple example, analyze its problem and come up with a solution following the Product Engineer mindset.
A Software Engineer approach
Let’s take a look at this simple project
You are working for an Automation marketing platform for E-commerce merchants. The product needs the data about the sales orders of the merchant and your task is to build a 1 way Sales Order integration feature to sync data from Shopify to your system
After going through several discovery steps with your customers and the PO, you decide that it’s time to make the implementation plan. You now come up with this plan
| Milestones | Details | Duration |
|---|---|---|
| Backend | Build the backend to handle auth & webhook requests from Shopify | 1 month |
| Frontend | Build the frontend for the users | 1 month |
| Beta | Release to some beta customers | 0.5 month |
| Bug fixes | Handle issues reported from customers | 0.5 month |
| Go live | Release to everybody | 0.5 month |
Sounds good? Yes, this is a perfect plan from a Software Engineer perspective, but…
Assume that it’s 01/10/2023 and you have finished the first Backend phase. Everything works as expected, you bring this to the weekly project update meeting and present to all the stakeholders. However, oposite to what you expected, they feel so disappointed. What has happened?
- They have been waiting for 1 month and they still have nothing.
- They have to be patient for another month, for 4 other project update meeting to start using the feature.
- The PO and QA have also waited for that long, sitting there without doing anything beside preparing all the test cases
Another month has passes, you now finish the beautiful frontend so everybody can start experimenting it. The PO now realizes that the workflow is so confusing, could lead to a lot of complaints from customers. They ask you to go back and change the main workflow. You say that the business needs to either extend the deadline or accept that flow because it would take a lot of time to adapt to this change. The whole team start debating because nobody is satisfied.
After several discussions, you have convinced the team to follow the original solution. It’s time to release to some beta customers. What the PO worried about has happened now. The customers say that the feature is too hard to use and they don’t really like this. It’s when the project really go off-track
How about making smaller milestones?
After reading the above part of this post, you decide to do it differently. You now go back and update the milestones like this
| Milestones | Details | Duration |
|---|---|---|
| Project setup | Scaffolding, set up server and architecture | 1 week |
| Connect to Shopify | Connect, authentication and sync first order | 2 weeks |
| Handle Sales order requests | Handle all webhook requests related to Sales orders | 1 week |
| Handle Product requests | Handle all webhook requests related to Products | 1 week |
| Handle Fulfillment requests | Handle all webhook requests related to Fulfilments | 1 week |
| Handle Customer requests | Handle all webhook requests related to Customer data | 1 week |
| Handle Address requests | Handle all webhook requests related to Billing and Shipping address | 1 week |
| Frontend | Display the data | 1 week |
| Others | Implement other small requirements | 1 week |
| Bug fixes | Handle issues reported from customers | 2 weeks |
| Go live | Release to everybody | 2 weeks |
Sounds better, huh? Yeah this is closer to the target. Smaller milestones make it easier to change. However, there are still some questions you need to ask here
- Do we look into this from the User perspective? What are the problems that you are trying to solve for your customers?
- What does it mean when you say
I have finished "Handle Sales order requests" phase? Does it mean that you finished setting up the API to handle that type of webhook requests? Or do you mean that you have completed the function to map from Shopify schema to your system schema? Does it include the frontend? Can the user start using it? - Or more precisely, the question is
What is your definition of Done?. Do you mean it’s done when you say it’s done? Do you need to go back and change it if the frontend doesn’t fit the data? - When the project goes off-track and you are going to miss the deadline, what features can you drop but not affecting the workflow?
Are you building a Software or a Product?
To be continued
A Product-oriented solution will be presented in Part 3