A Developer Must Help Their Client Learn To Be a Product Owner
TLDR;
Listen at ReadOrListen Podcast
As developers, especially those who freelance and work one on one with clients we sometimes have to help that client understand what we expect of them as a “Product Owner”.
As a freelance developer, my relationship with clients extends far beyond coding. The engagement is educational, helping clients become efficient product owners, understand the value of iterative development, and adopt a proactive approach to Quality Assurance (QA). Also on my end making sure I really understand their domain, their goals and help break down those goals into realistic achievable features.
While I may get paid to code, my ultimate goal is to build the right features. And this is rarely if ever exactly what the Product owner expected.
The hardest thing about a project is not the technology it is the act of communicating an idea to another person.
Terminology
- Domain: This refers to the business logic or subject matter of the product. Though the developer may have some experience here, it’s crucial for the product owner to have domain-specific knowledge.
- Product Owner: This is the person or organization commissioning the development work. Unlike a project manager, the product owner has a deep understanding of what needs to be built.
- MVR (Minimum Viable Release): This is the leanest version of the product that can be released to customers for feedback. For example, the first iPhone didn’t have copy-paste, and ChatGPT web ui initially lacked a history sidebar.
- QA: Both the developer and customer need to review a feature works as expected. Developers do this via tests and then making sure it is working via clicking through a feature. Product Owners do this by trying out the feature when deployed. Sometimes the “bug” can be that the developer misunderstood the requirement so this is key.
- Happy Path: When testing what a feature should do focus on the success path of the user or system that is expected to happen. Make tickets as you go for “later” to cover the unhappy path or bugs seen.
- Feature Flag: this is a technique of having a feature on production that only certain users can see and test.
Embracing the Build-Measure-Learn Philosophy
Before diving into development, it’s imperative for clients to internalize the Build-Measure-Learn cycle. This iterative approach involves developing a minimal version of a feature, measuring its impact, learning from the metrics, and making improvements.
“While I may get paid to code, my ultimate goal is to build a product that either people use or quickly prove otherwise and stop working on that feature.”
Here is an example, a client asked me to build a chat window that a user can use to ask questions about the domain of the site.
That chat window was talking to the OpenAi API. I used a simple component I got on the web, nothing custom to build and used feature flags I was enabled it for him and his staff.
Nothing fancy. The build took 1 day (less really), and the learning was
“is it really useful?”,
“if it is useful what might be a good next step” — sometimes something you can not even imagine , till you see the feature in front of you and use it
“is there a customer we can let try this”.
From here we only lose a day and end up with something that either can be deleted or extended or even just left as is while we gather more feedback.
For Developers:
Learn how to decompose an idea into manageable blocks for incremental delivery, maybe just a drop down menu is all you need to review or a login form but keep it small.
For Product Owners:
Make room in your schedule for regular check-ins. If you or your boss are not earmarking time for you weekly then this will never work out.
Why Waiting for “All Done” is a Myth
Forget 2 week sprints that is too long.
The notion that a product owner can hand over a list of features and expect a fully-baked product within a fixed time-frame is misguided. Being part of the development process is key. A modern tech stack should be able to deploy to staging or production easily and automatically. Using Feature Flags a Developer can easily show the client features that customers can not see. (article linked below). This should allow for a smaller step approach. Start the product with an outline of the goals. As each goal is reached check in and see what is the next goal, has it changed, and then move on from there. What was next before this goal might no longer be next. Forget 2 week sprints that is too long.
For Developers:
Maintain a consistent rhythm of client check-ins. Not scheduled but you should aim for every 2 days since a small feature should not take longer. If they are maybe break them up into smaller features/goals.
For Product Owners:
Plan for twice-weekly meetings (minimum), especially during the project’s early stages. If you or your manager are not freeing up 5–10 hours a week of your time for this then it is not worth starting the project.
Educating Clients on Quality Assurance (QA)
Quality Assurance isn’t solely about identifying bugs. It verifies whether the software meets user needs and expectations. For each feature talk about the actual business goals. List them out and then when the feature is ready to be tested by the client, knowing the developer has done some testing (code level and clicking around if needed), then test those and only those features. Do not get distracted by other bugs on the site (sure make tickets). And if you see issues related to an “unhappy path” then make tickets but that should not hold up the QA of that feature.
For Developers:
Use tools like Spreadsheets to list out QA steps and results. Or use Trello to guide the product owner through the QA process more on that later
For Product Owners:
Allocate time for QA and clearly articulate any issues for the developer to address. Stick to the happy path at first. Though as soon as possible deal with the unexpected paths discovered in this process.
The Pitfalls of Big Design Up Front (BDUF) and Over-Estimating
BDUF and overestimation are two practices that can derail a project.
The Illusion of BDUF:
Big, detailed designs may seem comprehensive but often result in a disconnect between the client’s vision and the final product. I prefer sketch-like tools like Balsamiq over intricate Figma designs, as they leave room for adaptation.
The bottom line is there is no way to build out every detail and flow of an application up front. It will just result in a lot of “lost in translation” moments that lead developers to build the wrong thing and product owners to not even be certain what the goal of the designed area was.
The Perils of Estimating:
Estimates rarely hold water. Many who provide them simply multiply the original number to include a safety margin, but this strategy seldom works.
For Developers:
Be forthright — even if it means losing a gig. Do not get caught in estimating and prediction timelines. For every day your feature(s) take to build there is nth amount of drift that will accrue. In the end you are developing under stress and the product owner will get the wrong thing delivered to them.
For Product Owners:
Educate yourself about these pitfalls and set a realistic yet flexible timelines.
This reminds me of when I watching the Project Greenlight (😖 do not watch it super frustrating) but one of the producers kept bragging about how she is always on time and on budget. BUT the films continued to be less than 60 percent ratings on IMDB. The point is not just budget and time but quality of the product. Reduce the product goals aim low and iterate.
Steps for Clients to be Effective Product Owners
I encourage clients to decompose their vision into smaller, manageable pieces. This not only enables more rapid progress but also allows for adjustments based on real-world feedback.
Continue to learn the Product Owners domain, ask questions and continue to break down the next step into a small, less than one day, deliverable.
For Developers:
Stay communicative. Don’t go MIA or get so far ahead that it becomes difficult to make adjustments.
For Product Owners:
Take the time to review and respond to all communication.
“The goal is to spend the right amount of money to build the right amount of product.”
Tracking Tasks
One thought here is using simple tools like Trello with the following “Lanes”
Later: Items that we can sort after the current feature is “done” and then decide which is next.
Next: This was what is now In Progress. It might be empty or it might just have a bug or bit of feedback from In Progress.
In Progress: Just so the Product Owner can see the one thing you are working on.
QA: This is the lane that feature goes to when ready for QA to talk about it and share the expectation and status of that QA
Done: Obvious
If a feature fails QA the team should talk and move it back to Now or Done and make “unhappy” path items in the Later lane.
Conclusion
The role of a freelance developer isn’t solely about churning out code. It’s about building the right things for the clients goals. We have to do what we can to help our customers build the product that meets the needs of the users and business and this is not always inline with the initial goals of a project.
## Links
The Lean Start Up
Wire-framing Tools
Building Blocks
Bugs are part of Software
Feature Flags
Estimating
Agile Esitimating
https://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
