View profile

Methodical Product - Development

                                                Read In New Tab A Personal Note I've quit my job, co
Methodical Product - Development
By Akar Sumset • Issue #11 • View online
                                                Read In New Tab

A Personal Note
I’ve quit my job, coincidentally, on my birthday. 
It’s been three weeks (now that you know the date, you know what to do next :) ) yet it feels like the best decision I’ve ever made. I know it is extremely early to tell if that feeling is going to continue or not but that’s how I feel now. You know why? I’ve instantly started devoting my time on things and people I really, deeply care about, at my own pace (which is not slow), according to my own schedule (which is truly busy but doesn’t feel so).
Don’t get me wrong. I’ve cared about my job(s) while I was an employee, too. My girlfriend calls me a workaholic for God’s sake. However, the difference now, is that I am doing the most meaningful thing only I can do (carrying our family business -leather goods and textile- to new markets in Europe, Australia, USA etc. . I’d appreciate any connections.) as well as things I professionally enjoy the most: consulting, speaking, writing and soon lecturing on all things product. 
Like these are not enough, I’ve also started ProductTank Istanbul (meetup branch of Mind the Product) and a side project (imagine a “RELIABLE” list of “best designers/developers/etc. in Istanbul/London/etc.”) which I’ve been dying to try for years. More on these on the next issue.

Back to Product… Development
We are at the 4th step of 5 D’s of Product Design and Development framework. Development sounds more like a step led -mostly- by developers. Well, it is. Here, we the product people play more of a supporting role yet this doesn’t mean that what we do during this step doesn’t matter as much as the things we did in previous steps. Being proactive versus reactive makes the difference here.

Intro and Purpose
Before going any further, let me explain what I mean by Development. It means that it is time to plan, code, test and ship. 
As you see the whole thing starts with planning. We already know that nothing ever goes exactly as planned. I always say that (maybe I heard this from someone, not sure) “A plan only shows how things will NOT happen.” 
One who expects a perfectly realized plan is either naive or have other plans… Yet this doesn’t mean that we shouldn’t plan at all. How come? Listen to this:
“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?
In planning, the purpose is not coming up with a perfect plan that reflects reality. No. Ain’t nobody got time for that. The purpose is thinking things through, having a coarse grained vision of how things should go in order to minimize uncertainty not only for developers but for the whole company.
“In preparing for product shipment I have always found that plans are useless, but planning is indispensable.” 1st son of his father, Akar Sumset

Overview of Development
The high level process is as following.

Grooming (We need more details for that… First, we need to refactor…)
Product Fine Tuning (I can’t change this!.. This looks like sh*t now!..)
Planning (We should be coding instead of talking… How is this X points?..)
Getting Buy - In (We need one more sprint to complete all these…)
Final Adjustments (The “business” was not happy but we removed this and that…)
Coding & Occasional Demos (How will we ever complete this on time?..)
-Freaking Out and- Course Correction (Aaarrgh! OK, now let’s try this and let me talk to the “business”…)
Testing -and More Freaking Out- (I can’t even login!.. This works on my local machine…)
Launch (Did we forget the release notes again?.. Is this feature supposed to be open to everyone?..)
Happy Hour (Hope there aren’t any critical bugs, I’m too drunk to fix…)
Why plans don't work
Yeah I skipped the first two steps and jumped into planning. Because it’s that crucial. Not for the reasons you think. (Sooo clickbaitish)

To achieve more realistic estimations, we better involve developers during Discovery, Definition and Design in order to engage them with the product, help them think through and spot product trade offs with great ROI (e.g. saving a lot of time with a small product change).

Planning Fallacy, Hofstadter’s Law, Unknown Unknowns and BrainF.ck
No matter how good we do all those above, there still is an incredible uncertainty in software development. Whatever we are building, roughly speaking, it’s going to be built for the first time. 
We might even be copying something but it doesn’t matter. Say, we are doing the “exact” same login feature as we did in our previous project. In product definition terms, it might be the exact same but when it comes to development there are so many not so obvious differences like the architecture, the 3rd parties, the libraries… which can cause unprecedented problems. Yet we always tend to be overly optimistic. Listen to Kahneman explaining why this happens.
The Real Reason Projects Always Take Longer Than You Think
Sadly, knowing that you are being too optimistic or even doing pre-mortems  as Kahneman suggested won’t save us either because of Hofstadter’s Law:
Kind of a recursive function as our more technical friends call it
Kind of a recursive function as our more technical friends call it
It’s getting frustrating, isn’t it? At least knowing why that is so might give us some rest. So, let’s listen to Donald Rumsfeld and understand why.
Donald Rumsfeld Unknown Unknowns ! - YouTube
Donald Rumsfeld Unknown Unknowns ! - YouTube
How to plan so that it works
Not like this.
Not like this.
First we have to accept that there is no golden formula. But, we still have ways to make it work. Starting with listening to Bezos.
Nailed it.
Nailed it.
Yes, an awesome principle. However, we know that principles are only useful when coupled with methods. The single best method I’d suggest is called Time Budgeting. Here is an awesome step by step guide on HBR.
Well, the reality is that it is very unlikely to adopt this method as a replacement to the traditional methods like waterfall or scrum. What we can do is to adopt this approach a bit more implicitly. What does that mean? 
Implement Time Budgeting Disguised as Time Estimation
1. Position Time Budgeting as a way to get “guesstimates” or as a way of grooming. 
2. Define what aspects of product exceed the expected timeline and increase complexity.
3. Prepare yourself for sacrificing those aspects on the course of development and start managing business expectations accordingly.
4. Watch how development progresses closely and act proactively when you sense risks. Try to understand if any sacrifice would help.
5. Inform all stakeholders as soon and honest as possible with the changes, why you had to implement those changes and how you plan to make up for them.
Why go through all this?
Yes they will.
Yes they will.
Conclusion
Honestly, this was one of the most fun issues I’ve ever written. I don’t know if it’s because I’m writing this while I’m next to these fellas below or I know that I’ll wake up to a Monday without an alarm clock after years. Regardless, I’ve enjoyed this issue a lot. Hope you did too.
Chicken. Ultimate garden sanitizer.
Chicken. Ultimate garden sanitizer.
Next issue will detail the steps in Overview part and include tools, methods and frameworks.
Help!
1. As I mentioned at the beginning I’ve started working with my family to spread our leather business to new markets like Europe, USA, Canada, Australia… wherever possible. I’d appreciate any connections.
2. I want more subscribers. (This didn’t sound that weird in my head) Even seeing the number of subscribers, let alone the great feedback, is motivating. Share or forward this issue to help.
Bonus
The Surprising Relationship Between Gamification And Modern Persuasion – Smashing Magazine
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