View profile

Methodical - What Do Product People Do While Devs Code?

The last time we spoke, I told you how I left my job and started a new venture (a leather company) wi
Methodical - What Do Product People Do While Devs Code?
By Akar Sumset • Issue #12 • View online
The last time we spoke, I told you how I left my job and started a new venture (a leather company) with my family. It has been very time consuming for sure. However, the real difficulty was how mentally tiring it is to transform one’s self from a digital product person to a physical product designer, from being an employee to a bootstrapping entrepreneur, from building products to building and selling them. It’s hard but fun, too. Now that it’s showing good signs of getting on track, I feel much better about devoting more time on digital products, hence this belated issue. 

Enough about me. Let’s get going. We are at the 4th step of 5 D’s of Product Design and Development (note for new subscribers: 5 D’s is a framework that I “made up” marrying product management and user experience design). The last time we covered why it is worth planning although plans don’t work. Now it is time to deep dive into the whole Development step.

How to plan so that it works
Although things never exactly go as planned there still is a lot of value in planning. How come?
“In preparing for battle I have always found that plans are useless, but planning is indispensable.“ 34th President of the USA, Dwight Eisenhower 

Very well put, isn’t it? Now that we are convinced that it makes sense to spend time on planning, let’s remember what kind of an approach is meaningful in the light of Eisenhower’s wisdom. 
The right approach comes from Jeff Bezos:
Be stubborn on vision, flexible on the details.

And, as always, here is a great method to apply this principle in practice: Budgeting. Simply put, instead of estimating how much time/money/resource etc. our product will require, we start with the budget we are willing to spare. Here is a great step by step guide:
Read This! Or Don't.
The following is a step by step guide for the things product people can do to actually deliver products on time, in budget and more importantly in a way that satisfies both users and business as well as people building the product.

  1. These piece is a very tactical one. Hence, the bullet point style.
  2. Keep in mind that from here on “product” means a feature or a story as it is usually called. Meaning, the “product” is not as complex as a whole app rather it is just a piece of an app. Imagine we are talking about Voice Messaging in Whatsapp instead of the entire Whatsapp app.
Grooming means love. At least for wise creatures like horses.
Grooming means love. At least for wise creatures like horses.
  • Make sure the attendees have a basic understanding of the product(s) you’ll be talking about. You can achieve this by making sure everyone has read the Overview part of your documentation either before the session or at the beginning of the session like Amazon does in their meetings.
  • Since Grooming is about exchanging ideas, there’ll be a lot of rough edges to smooth out. The important thing is to smooth out edges according to the user goals, business goals and your principles. Otherwise, you can smooth things out to the point there is nothing to smooth out. After all, there is nothing smoother than emptiness, is there? (Smooth…)
  • Another helpful concept for grooming again comes from Amazon. “Be stubborn on vision, flexible on details.”
  • There is a lot of unknowns at this stage. This is the reason why we do grooming. However, remember that people associate lack of knowledge with incompetency. This is almost inevitable for most of us. Being a product person means being a leader and leaders can not look incompetent. So, to minimize the risk of looking incompetent use all the knowledge you already gathered to build the right product. Cite user feedback, present data from your internal sources as well as external sources or present the results of your benchmark studies.
  • Manage the session with confidence. (Related to the point about leadership above.) Be very strict on the timing. Control the course of debate, make sure it doesn’t slip to unrelated topics and doesn’t get emotional.
  • Make sure everyone is heard and also feeling heard. Yes, these are two different things. Just giving people turns to speak is not enough. Listen to them attentively, use simple tactics like summarizing what they said and thank them for expressing their point of view.
  • Dive deep if people go “hmmm… how can we even do this?” or “we can figure this out later”.  These kind of expressions usually signal there is something not well understood or unknown. Question it.
  • Ask what are the things going to cause biggest pain or consume the most time or most confusing. Clarifying these will make the actual development much more predictable and much less stressful.
  • To get a sense of effort without making people getting on the defensive don’t ask “how long would this take?”. Ask for a comparison with previous products you built.
  • Make sure notes are taken (the best way for me is to assign someone to take notes) and publish them ASAP to conserve the momentum.
Product Fine Tuning & Getting Buy In & Adjustment
Change request? More like party request!
Change request? More like party request!
  • Review the outcomes of the Grooming sessions together with your product Overview. Find out if there is anything crucial that needs action and initiate the action.
  • If there are any important changes to the scope run it only by the involved stakeholders.
  • When you run by these changes make sure you deeply understand why there is a need to change and how you plan to compensate for the change.
  • Do not procrastinate on these kind of situations. It’s better to have this kind of discussions as early as possible so that the involved parties can align themselves.
  • Try to minimize the pressure on development team and only involve them if it is absolutely necessary.
  • To be able to do the above you must make sure that you’ve pushed the limits in order not to cause changes as a team.
  • Once you got buy-in inform all involved parties of the change and initiate adjustments needed.
Developer stretching. Classic.
Developer stretching. Classic.
Coding & Course Correction
(We’ve jumped to coding and course correction since we already covered definition & design as well as planning)
  • Now that you clarified an enormous amount of unknowns and finally get to coding, it is understandable to feel that it’ll be much more straightforward from this point on. Well, it won’t.
  • Coding is not a menial task. The problems solved with coding is not about translating product definition into “machine language”. Coding has its own challenges like being efficient, scalable, readable, secure, in-line with existing architecture, dependencies to external libraries, changes in browsers, frameworks or application stores etc.
  • So, we better keep a close eye on how “coding” goes even though it is not our job as sometimes there are other departments/roles like project management, scrum masters, development managers etc. to oversee this step.
  • A useful approach to keep close to coding is to occasionally and unofficially visit development team and ask them to show what they did, if there are any obstacles and how you can help.
  • This way, you’ll get to sense what might go wrong and prepare for fixes. Fixes can be anything from simply asking for more experienced people to help to adjust the scope or even completely abandon the work.
  • However, this never means being OK with a shitty product. Better be OK with less than to be OK with shitty. 
Imagine how difficult and fun it'd be launching like this.
Imagine how difficult and fun it'd be launching like this.
Testing & Launch
  • Test your product yourself frequently and as early as possible. It doesn’t matter if you have a QA team or some other kind of testing solution.
  • Purpose of your test is not only to detect bugs but more importantly to see if the product is working as expected according to user goals and business goals. 
  • Additionally, you might find some rough edges where a little polishing will improve the product greatly.
  • Make sure you test it as close to real life situations as possible. For starters, do not test it on your gigantic iMac or super fast Macbook. Don’t test with extension free browsers. Install ad-blockers and some popular extensions. Test with wi-fi and without wi-fi, with a password manage, test in incognito mode etc.
  • Ask people in your organization to test it while you watch them. Ask people never saw the product to test it. And the best of all test with real users either in house or by releasing to a beta group or by doing an A/B test  or by releasing to only a fraction of your users..
  • Have some kind of a checklist that needs to be checked before pushing live. Something similar to Definition of Done of agile practices.
  • Some examples: Release notes for app stores, announcing changes via mailing, internal announcement, scheduling user session recorders etc.
  • Check if analytics is working as expected and then celebrate!
It is not easy to be involved with the development teams if a product person doesn’t feel confident of their technical background. However, having a technical perspective is not the only way to contribute during Development. As we saw with last two issues there are lots of room to contribute as a product person from helping developers to better internalize the product at hand to help teams communicate better and thus mitigate risks. The key here is to be pro-active. In the end it’s all about shipping not designing.
Did you enjoy this issue?
Akar Sumset

Hey product person! Can't choose what to read? Can't trust what you learn? Methods (frameworks, guides, principles...) are the solution if you know when and why to use them. Unlike other newsletters, Methodical shares content in a structured way so that you know when to use what.

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Disbudak St. 17, Besiktas, Istanbul, Turkey