Note: This article was written when the website was still being developed (~28th Dec). It is currently live and has gone through 2 iterations of bug fixes. Check out photography.rkakodker.com. Your feedback is welcomed!

I’ve been a tinkerer all my life. Technology fascinates me, like nothing else. I also like to photograph. I thought, over the Christmas holidays, I’ll dive into the minds of developers, designers & PMs by being one at every stage. Surely, after 10 years in Product Management, dealing with hundreds of developers and designers, nothing could surprise me, right?

Wrong.

Even in my little mindspace, I struggled to switch hats. From being the designer, asking for the designs to be respected in development, to being the developer, trying to find ‘intelligent shortcuts’, to delivering — all the while attempting to bring those two sides of my head to agree to meet the self-imposed deadline.

I’ll give a brief outline of the process that was followed before diving into the learning. You can skip the process to go the learnings directly.

Note: To achieve this, I essentially broke myself into 3 people — the developer, the designer & the PM. They’re referred to individually, in this article, but they’re all the same person: me. Different sides of me were given a free rein in my head to achieve this. It’s difficult, to say the least. I’ll refer to them in the third person to avoid confusion!

The process

It started, incorrectly, with technology.

I’ve been a fan of WordPress, ever since I could write PHP. But, with the advent of new CMSs and no-code players in the market, I had to do a ‘discovery’ session to understand what tech would support my needs.

While diving into the technology, I realized I missed out on the biggest lesson of Product management — What is my workflow?

You see, the presentation doesn’t matter — it’s a static website at the end of the day. What matters is the backend for uploading content & tagging it and, the ease & comfort for doing so… I can now do the majority of the Lightroom work on my phone… add to that the fact that in the last trip I took, 50% of the photos were from the phone. It’s a no-brainer that I need a way to upload content via my phone.

So, I wrote out the expected workflow, trying to keep it as unbiased as possible. However, at the end of the day, it turns out, old habits die hard. WordPress was the way forward (I’ll detail why in a subsequent article).

Moving forward, once the technology was finalized, I switched out to the designer side. After exploring a ton of photographers and their websites, I finalized a particular layout.

There were frequent interruptions from the PM & the developer — but I took breaks from designing to satisfy their needs (of exploring alternatives, comparing styles, and looking for Codepen solutions that fit the requirement).

Once the first 3 screens were finalized, the PM took over and a detailed plan was made with the help of the developer.

The developer took a frightfully long time to set up the development environment and was very distracted due to cross-OS development opportunities (I have a Windows & a Mac — and I shuffle between them).

The WordPress development scene has changed quite a bit from 2012 when I was active. So the developer decided to watch a couple of videos. Once he figured out what worked, he started.

The problems

And that’s where the problems started.

You see, at every stage, when a problem was encountered OR when a Codepen solution gave more than what was asked, the designer & the PM were brought in to take a quick decision. Every night, the developer would come up with new options to ‘optimize’ or simplify the workflow. Twice, new options were explored that led to nowhere.

The designer was frustrated! The designs were not being followed — just used as a reference! And it felt that both the PM & the developer were against the designers’ pangs of having to change an approved design.

“AGILE” they screamed — while the designer made changes to all the screens, manually. He hadn’t done the whole components setup business in Figma and now was spending valuable sprint time in making those changes. The PM wanted to see how those changes would impact the rest of the site.

With only 3 days to go to the delivery deadline, the developer got into serious mode — no more distractions from the PM or the designer (who somehow always found time to suggest improvements in the UI). In 3 9-hour hackathons, he finished the entire website development work!

The PM decided, at the end of the last hackathon, that running Lighthouse would be a good idea to measure performance… it was, obviously, a bad idea. Code wasn’t optimized and they only had a day to go!

After speaking to the higher management (my wife, who graciously offered to postpone her plans with me by a day), the PM came back to the team asking what can be done in a day. The designer wanted to add more UX functionalities, while the developer wanted to optimize. A deal was struck that only the low-hanging items would be tackled in the day and the theme would be made ready for production.

At the time of writing, the release is failing in production and the PM has decided, ironically, to write about his learnings.

The Learnings

The entire process is a fun learning experience and I encourage you to find a couple of folks (who can design or develop) and run this process. You will find that the learnings are common — and the variations are usually a function of the person you’re dealing with… If you can’t, I’ll save you the trouble. Note that these may also be what you’re experiencing as a PM/Designer/Developer individually.

If all you have is a hammer, everything is a nail.

I’m a terrible developer, an OK designer, and a good PM.

In the discovery phase, the developer overtook the entire process and made the main issue as technology. Being a terrible developer, I was forced to seek out ease before end-user convenience. Only when the PM intervened, when the selection (and therefore POC work) piece came along, that I realized that having the final end-user understanding is critical to the discovery process. Sure, using Ghost would make things easier for the developer, but the entire backend and upload process would be tedious! The lesson here is simple:

Have the knowledge and validate your end-user experience on paper. It makes decisions simple.

I missed out on this.

My second mistake was to assume that I knew WHO my end-users were: the website visitors. The more I thought, the more it became evident that without content, these users wouldn’t see anything (or even visit!). I had to optimize for my true end-user — me, the content uploader. If his experience wasn’t easy or accessible, the entire project would fail.

The lesson from the overall experience:

We are slaves to our shortcomings. No matter the shortcomings within the team, stick to the process. Tackling the problem head-on has repercussions down the road.

Separation of concern is overrated

PMs always talk about separation of concern — the developer should focus on delivering the design and functionality as written out in the user story. The PM shouldn’t get involved till the development is complete.

All horse-shit I tell you!

It was amazing to work as a trifecta. Dealing with the developer’s immediate challenges to solve them through either design or priorities. E.g. when building a slider for the website, the OOB functionality did not provide for auto-image sizing. There were severe limitations on the slider itself, which the designer quickly found out, redesigned, and provided.

Sure, it could be solved in a few hours — but those hours were precious (for I am a terrible developer).

Prioritization came into the picture when a responsive version of the site would break (despite using Bootstrap 4). The PM said, F-it! Viewing the website on a lower form-factor wouldn’t bring out the beauty of the images anyway — while the developer & the designer were confident that they could solve it — given a few more hours. Ultimately, the decision was made to postpone responsive development.

The collaborative nature of the process not only helps you solve mini-challenges but also exposes you to the thinking required to build great products.

The lesson here is:

Collaboration is essential if you want to have a working product. Otherwise, the sense of investment in the product reduces drastically

Scope creep is acceptable, and should be managed properly

While the developer was looking for a solution on content alignment on Codepen (again, horrible developer), he came across a cool typewriter script.

The team was called in: can we add this to the backlog? The PM was sure this would add to the experience on the website, making it a ‘sticky’ feature, while the designer was skeptical — this would lead to more design changes and further changes in the UX.

Since it was a one-man operation, I had to choose:
Do I go down the path of seeing the complexities in the UI for this ‘typewriter’ effect, OR do I see if it actually works in my current site?

After a quick debate, the developer & the designer decided to work together — they would tackle each challenge as it came, keeping in mind the overall user experience. The PM was happy he was getting a new functionality, but the cost of the development delay weighed on his mind.

The ultimate solution was to compromise. The functionality was added, but at a cost — the PM would lose out on category view (pushed to post MVP). The lesson here is:

Scope-creeps, especially those from within the team, are to be treated as a creative outlet. Understanding them in the context of the bigger picture (the time cost vs experience improvement) and subsequently prioritizing them, helps to bring out the best within the team.

This does not mean that every scope creep has to be included in your sprint backlog. Only those that truly add to the functionality. The MVP definition is fluid and should focus on meeting user experience.

Time management is critical

I cannot count the number of times each party in my trifecta went down the rabbit hole. For hours, a particular functionality, design, or experience was tested to see if it fits the bill. I must have taken at least 30% of the time in rabbit holes — only getting 2–3 new outcomes from it.

Was it worth it? Yes.
Was it worth the entire effort? No.

You see, when you go down a rabbit hole, after a while, you get an intuition that it may not work out. Despite my terrible development capability, it became clear that the rabbit hole wasn’t worth it. And yet, I stuck to it… for satisfying my sense of curiosity. Combing through Github issues & Stack Overflow, to look for a solution, only to find that it isn’t possible with the current configuration that I have… the most common being the carousel library.

After 2–3 days of finding myself deep in these rabbit holes, I decided that after every hour, I would ask myself — is it worth it? Calling the PM & the designer to the discussion. We’d make the decision if going down further made sense. I have a chicken-timer (Pomodoro, but a chicken instead of an apple) that reminds me that an hour has passed. It was good to snap me back to reality.

The lesson:

Time-boxing is critical. Time-box your discovery, POC, and other sessions. It is tempting to keep attacking the problem in hopes that you’ll get an elegant solution. You only end up getting diminishing returns.

Another lesson — when in doubt, collaborate!
The PM is good at weighing pros & con’s and as long as he has the right information, he can quickly give you direction. The designer is good at assessing the impact on experience, in the absence of functionality.

Listen to them, and make a decision. Making a decision is far more important than waiting for information.

Stand-ups are less important than what happens after

Most PMs that I know disappear after a standup. The team is left to their own devices — to decide what to do next. I didn’t have a standup per se — just an assessment of what is left & what was done. But, in the real world, a PM’s role becomes more important after the standup — when there are critical decisions to be made around the development & design.

This doesn’t mean stand-ups are useless — they are important, but PMs have to be available all the time to ensure that both effectiveness of the team and the backlog are always prioritized. This requires deep collaboration.

MVPs are minimum viability products, not benchmarked products

When the website launches, hopefully, before the year-end, it will be without some of the critical default functionalities — like SEO optimization and deep analytics. I simply didn’t have enough time to do that.

And, honestly, that’s ok.

You can launch a site in 2021 and not have SEO functions, right away. I have it on my priority list — but I cannot do anything to SEO till I start uploading content. Similarly, for analytics, other than the basic tracking, I cannot do more without actual traffic on the website.

When I started, however, I had those two things as part of my MVP. They were critical. I quickly realized that I wouldn’t have them, as the development process rolled out. And that was OK.

MVP definition has changed over the years, however. Corporates define MVP as a complete marketable product (more like an MMP) that has all the basic bells and whistles. That puts undue pressure on the team and gives no scope for creativity. The ‘typewriter’ feature came at the cost of these basic functions — I won’t trade that for any basic functionality. Sure, I don’t have SEO right now, but who is visiting? My focus is on content building and adding those functions once I have a critical mass of content.

Lesson here:

It’s OK to skip out on basic functionality if it helps to unblock other critical functions around the platform. Visualize the steps for a feature to be non-negotiable. And then prioritize.

What I mean by that is — since content generation is a priority and without content, there is no SEO/Analytics — and I do not know the variations in the content (I have a generic idea, but as I start to upload images & projects, I will come up with new content types — this I know for sure), I cannot put in SEO functions. Similarly, for tracking — other than basic GA integration, there is nothing more to do, till the content is there.

For any feature to be critical (or non-negotiable), some steps are needed to make it so. Know what those steps are and prioritize accordingly.

Your estimates may be terrible, but eventually you get better

Ask any developer how long it’ll take to solve a problem, they’ll probably give you an inflated timeline. That inflation isn’t due to a lack of understanding. On the contrary, it accounts for uncertainty.

When I started, the developer had a very ambitious delivery timeline of 3 days. It’s day 8 and we’ve miles to go to reach the MVP.

What I noticed was, as the development process go more involved, the estimates started getting better… by Day 4, I could predict, to a large degree , how long a certain feature would take… The lesson here is:

Don’t berate the team for sharing inaccurate estimates. Empirical evidence takes time to build, and no matter your experience, you’re bound to make mistakes. Time, alone, gives your team the ability to make fewer mistakes.

This brings us nicely to the next lesson on Agile. It focuses mainly on the mindset, but a key tenet there is about uncertainty, and how embracing uncertainty helps in delivering predictably.

Agile mindset is harder than you think

As PMs, we’re usually championing Agile & agile concepts wherever we go… but when you go through the process as I did, you’ll find that holding onto the mindset is harder than you think.

At various points in the development/design journey, it was taxing to hold on to the mindset. The PM wished the developer would stop exploring or the designer would change things in the design based on new things he discovered. The pressure (though self-imposed and artificial) was taxing — I was balancing family obligations along with the project here. If only they could deliver on the commitments, I would have been done with the project and moved on to the next thing.

Fortunately, that wasn’t the case. I forced myself to keep the whole thing fluid. Let the scope be impacted, the PM said — we’ll see what happens. That freedom that I allowed my trifecta was amazing (and refreshing). Rarely does one get this in the real world!

This is where the main problem with Agile in corporations comes in — The agile mindset demands that you let go — let go of the control that you so desperately want on the project timeline and scope. I am still afraid of the criticism that I will get — especially from Google on the page rank of my site. I do not know what the score will be when I go into production and upload the images. And that’s OK. All I’m certain of, is that I will make the necessary changes once I’m ready for them.

Agile thrives in uncertainty. You are supposed to embrace it and accept it as it comes, trusting the team to do the right thing.

Have fun

If you’ve to learn one thing from this whole experience of mine, learn this:

Have fun doing what you’re doing. If you cannot enjoy the process, the process needs to change.

And I really mean it — every night I spent breaking my head over why the PHP function was throwing an error or combing through Dribble for inspiration, was a fun experience. I enjoyed solving those problems. The PM enjoyed the introspection and alignment process. It was thrilling, to say the least.

Thank you for reading. I hope this has helped you in someway. Please leave a clap and subscribe for future updates! Let me know if you need further explanation on a specific aspect of my journey on this.