I am not a huge fan of LinkedIn’s cover image. Its an odd-sized banner that gets overridden by ads and the profile header itself. The flip-side of not having one is that it makes your profile look very lame. After all, a picture is worth a thousand words.
A couple of iterations later, I put up a metaphor of my professional side as the cover image. What do you make out of it? I’d love to hear in the comments section.
a.k.a. Why & How Product Managers must assess, account & groom technical debt
When I started conceptualizing a new product 5 years back, the concept of technical debt only existed in theory. Over a period, the pressure of time & customers, drove features cuts, compromises, and unfortunately, some quick-and-dirty solutions. Post the short-term wins, its not too long before technical debt surfaces and forces a resolution.
Technical debt is taken up for short-term advantages such as shorter time-to-market, and preserving capital. But in the long run, it reduces productivity, time available for new feature development and, God forbid, might keep you from crossing the chasm.
While Product Managers balance out the short and long term benefits/impact of every product decision, it is important that they keep track of the debt that is being baked in with every story. At the same time, having some framework to preempt the debt that is inadvertently introduced and proactively manage it as a roadmap item.
Fowler categorizes debt as Reckless v/s Prudent, or Deliberate v/s Inadvertent. While this classification answers the ‘how’, it doesn’t provide visibility into ‘what’ and ‘where’ of debt is added. Without further classification, accounting debt is like having a balance sheet with just one account for liabilities. I would like to further categorize all the debt that is deliberately added and assess its risk upfront. Here’s how:
| Type | Potentially lacks.. | User Visible | Sales Risk | Ops Risk |
|---|---|---|---|---|
| Business value | Comprehensiveness in all business scenarios, Browser/Language support, Super admin rights, etc. | Y | Y | N |
| User Experience | Simple task flows, help cues, consistent design, mobility, Usability or A/B testing | Y | Y | N |
| Performance | Quick response, High availability, Clustering, CDN, Load/Stress test suite | Y | Y | Y |
| Maintainability | Data redundancy, Recovery, Migration, Configuration management, Sizing estimates, Documentation | N | N | Y |
| Design/Architectural | Portability, Modularity, Coding standards, & styles, Web services, Latest component versions; Has glue or duplicate code | N | Y | Y |
| Test Automation | Comprehensive coverage of functional/unit tests, either brittle or missing | N | N | Y |
If you’re wondering why (missing) features and defects don’t show in the list, that’s because they are the fundamental work units for development and not actually debt.
Using the above framework as checklist for all new feature development, even non-technical Product managers can easily assess Continue reading Technical Debt Assessment framework for Product Managers
The beauty of Agile is the fact that its just about a few principles. – which we also summarized in a few words. Everything else is under your control. And on your way from classic waterfall practices to adopting those principles, you are likely to encounter some serious blockers. I’m attempting to list out the top 5 along with the Agile principles that they block.
Blocks: Velocity, Working together
It is uncommon to have a cross-functional team of teams with 30-50 folks working on the same product. While the Agile deliverable is a few days of work, large teams working on a single release will generate a huge deliverable that is more coupled, has wider impact and demands extensive testing.
Blocks: Working software, Simplicity, Accepting change
Teams that have a fixed-scope mental block start off by committing a scope for the next release, and then estimate a future release date. Since estimates are often incorrect, the release is delayed to deliver the committed scope – which is just not Agile. Forget about changing requirements, folks won’t even drop a few stories or acceptance criteria at the very end, to meet the committed date (time-box) – at the cost of Continue reading The Top 5 Deterents to Agile
As part of a recent Agile training, we were asked to summarize the basic tenets of Agile in 3-4 words. Our group, with Mahesh, Yuti, Apeksha, Shahdab, Dhwani, Jay, came up with the following:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Deliver value to satisfy
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Accept changes willingly
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Prioritize, Breakdown, Deliver frequently
4. Business people and developers must work together daily throughout the project.
Close collaboration, daily
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Everyone in the software industry, has at some point of the other, been part of a delayed project. The result is often a war room where all the big shots put their heads together to save face. Imagine one such meeting where everyone is focussed on crashing time. Management is willing to compromise margins and the project manager has been given the authority to do anything it takes to deliver the project sooner.
All eyes are on the development team to see what they can do to expedite. Desperate, the project manager thinks he has an offer the Dev manager can’t refuse. He takes pride in offering to add more resources to the project. The Dev manager, however sane otherwise, goes ballistic on hearing this and yells out: ‘9 Women Can’t Make a Baby in a Month’. There is a moment of silence. Then, the noobs giggle, the big shots calm down and the PM walks out of the room.
This is Brooks’s law, and every software engineer gets exposed to this mantra/joke – whichever way you take it – in the very first years on the job. If Pressman was as bold as Fred Brooks, he would’ve added it to his Software engineering bible. This is 100% true Continue reading Don’t be desperate to crash time
Aditi had done her bit of making our wedding cool by getting me to do a pre-wed photo shoot – that turned out awesome thanks to Frames of Mind. It was my turn and I had to prove to the lady (who had agreed to risk her life with me) that as a Product Manager I was creative enough, and thought of surprising her with our own “wedsite”. When the question of build-or-buy came up, I couldn’t find anything that matched my needs and the flexibility I needed to fiddle with it. So without much thought, I created a sub-domain, grabbed a copy of Bootstrap and got glued to NetBeans. I released the first cut online in less than 8 hours of work, and improved it over the next couple of weeks part-time (24 hours in all I guess). And yes, it really cost me $0, because I had already purchased hosting space and the prasadgupte.com domain.
The pre-wed shoot had given us quite a few fun pictures, and together with the nimbu-mirchi trick Continue reading What went into our lovely wedsite
In the last couple of years that I’ve owned an Anrdoid, I’ve tried everything from ColorNotes to Any.Do to store small bits of information. Trivial stuff such as
Such information that needs to be handy is usually lost under complex navigation menus. I’ve seen folks saving this information as draft messages (SMS) or even using memos which does not allow tags & full-text search. And that’s precisely the problem I tried to solve with Bitstore.
My hands were yearning to write some code and this couldn’t have been a better time to try out mobile app development with PhoneGap. Before this, I did try installing the Android SDK but the learning curve seemed quite steep, and after all, my purpose wasn’t to develop coding skills. PhoneGap with jQuery mobile & Jasmine for unit testing Continue reading BitStore: the simplest app to store & access bits of information
Google Reader had been a close buddy for quite a while, after Chitresh Jain got me addicted to a bunch of feeds, most importantly FMyLife 🙂 And then comes the sad shut down news that creates a lot of rant all over the web. After trying a few alternatives immediately, I was hopeful (and sure) that this would tickle opportunists and deliver a much better RSS reader. The threat of data lock-out that Google users were anticipating after the announcement was more than relieved with Google TakeOut and their commitment to Data Liberation (FYI, this was #6 on my list of the top 7 non-functional requirements for web-based products). And I am huge fan of the Google PR team. They made good sound great, and bad sound hopeful. And they’re so unbiased, they even delegated listing out the best alternative to end users itself.
Early July, Google Reader finally went down – RIP Reader – and I was exposed to Feedspot through Anuj Agarwal‘s bio on Quora. I had some troubles importing my subscriptions directly from Reader, but that looked like a problem at the Google end. It gulped the Reader TakeOut export without a hitch.
Configurability is the ability to change application behavior (functionaility) and the interface by changing application parameters, without the need to rewrite code. This can either be done in the front-end by users, or through back-end configuration. On the other hand, customization requires making change to the application code to modify existing or support additional requirements. Sophisticated application design (e.g. web hooks) can permit customization by externalizing the new functionality. But modifying existing functionality in a multi-tenant application is really not advised.
I am sure that the way I have configured my mail client or tablet’s home screen is different from yours. The reason we love modern-day apps and operating systems is because they let us configure the product to match our specific needs. Configuration is not a new concept – even old radio transformers allowed listeners to tune into the station of their choice without having to open any screws. Configurability isn’t a feature; its a vision. And it doesn’t come free; too much of it will also backfire. There are at least 3 compelling reasons why product managers need to plan configurability around every feature:
No product is designed for a single customer. And it would be rare that 2 customers had similar business processes. To adapt to the difference, without having to create customer-specific code bases, an application needs to be customizable. Gone are the days when customers would 200% of license fees on getting the product customized to match their business needs. In today’s scenario, solution providers need to cover the cost of customiztion through one-time implementation fees.
Besides, customers are not looking at multi-year transformation projects with huge budgets. Project managers need to create compelling business cases and promise hard dollar recovery through the proposed solution. Every project is like a turn-key project and a vendor has no chance unless they can promise rapid implementaiton and unlock the RoI in stipulated time. Continue reading Why PMs should consider product configurability early on
