Features

---

Here am I again staring at the laptop screen thinking: Is it time to talk about technology stack definitions and decisions I had to make for the blog? Bear with me dear reader we will get there eventually but not in this post! This is where the IT Architect that lives in me wants to talk about capabilities and features first before we even think about technology. Furthermore, I have to be honest with you and this is actually what I did when conceiving this blog.

Why I feel this is important and we need to talk here? Well, because half of the features you build are actually waste. Think about this stat for a second. This is insane! It is like paying for two cups of coffee and drinking only one throwing the other one in the trash bin!

Let´s do an exercise together to see this in action. Think about the last time you had to present something. You decided to use Microsoft PowerPoint for this slide deck. You went there, created a new file MyAwesomePresentation.pptx and started adding some bulleted texts, some images, maybe you also inserted a video and if you were audacious enough some animations.

Now the ask, how many features you used for this awesome presentation?

I´m pretty sure that if we count, we used less features than what is presented in a single PowerPoint "features" tab alone (a tab example in the image above). If we take all the available tabs in the app, considering that each tab contains a guesstimate of 10 features... Oh boy! That long list of features that were part of the PowerPoint project were a waste for the vast majority of the users!

This happens mainly because of two reasons:

1. Big Design Up Front

I remember when I was reading about Extreme Programming - a.k.a. XP and an article mentioned BDUF without explaining the acronym and I was like: what?!?!

This concept is linked with the past belief that IT projects should be managed just like any other "construction" project using waterfall methodologies. The parallel was obvious at the time if waterfall project management work for constructing a house it should work for constructing software as well: First build detailed requirements, detailed blueprints come next in the design phase after that move on to implementing/constructing the thing, the team does some verification/testing prior to release and finally a warranty period after the release to fix some inevitable bugs.

If you never had the privilege of participating in a waterfall-like IT project, it kind of goes like this: A single analyst from the "business" is assigned to help with some "IT project migration" that impacts 100 users. The Project Manager (PM) asks first for requirements. In the kickoff meeting, the PM mentions change management (not in a welcoming way) with long forms, stakeholder re-alignment and project deadlines impact. This is pretty simple in the business analyst head: will add as requirements everything the software had before + new things the single analyst thinks is important. Review of existing features to see if they are actually used? No. User research with the other 99 users? No. Validation of the new things this 1 analyst want? No. Here it goes ladies' and gentleman: the waste!

Very important note here: Do not, I repeat, DO NOT go from Big Design Up Front to No Design Up Front.

You and your team should be able to find a happy medium and a Rough Design Up Front is actually a good thing and will help a LOT to avoid waste (that is once more is what we are doing here!)

2. Falling in love with technology (or in some cases to the vendor´s pitch) instead of falling in love with the problem.

"I´m a <insert cool title here> and read a random article with 2 likes in medium about a new groundbreaking technology for blogs that transform every post comments into a Facebook comment in the Facebook post page, sounds amazing let´s do it!"

Is it? Really? Is this feature linked with the goals we had listed in our motivations post? Is it linked with the strategy/plan we built in the second post? Does the users/readers want this capability? How will you validate the hypothesis that users want this functionality?

Most important, after this feature passes the Mom Test (great book by the way) and when we measure the results with some sort of A/B testing, are you willing to kill this feature if it doesn't achieve the expected results?

In summary, don't fall in love with technology, fall in love with the problem and let go unused features!

Uff... that was a long answer to the "why this is important" question!

Going back to the features for the blog, how can we get them? This is again a case where there are many many many tools/frameworks/techniques out there than can help (seriously, take a loot at game storming to see how many options are there!). I´m listing here two that I used in the past, I like and can help in this feature generation/validation phase:

• Brainwriting - Idea generation technique
• Empathy Map - A method for understanding audiences

I am working solo in this blog so brainwriting seems like a better fit. The topics/questions I asked in my head when doing the exercise: What do I like when I go and visit a blog? What do I dislike? What else I have seen that can be incorporated to a blog that will help with engagement? What is the minimum set of features that other blog/writing platforms offer such as Medium? Lot´s of ideas came in for blog features, take a look at some of them:

• Create a menu item to post the materials I want to share it broadly
• Recommendations page with coffees, tech gear, books and whatever else I want to recommend (beer? why not)
• Progress bar while reading the blog post
• Search capabilities
• Dark theme for the blog
• Automatic translation from English to Portuguese
• Mobile friendly
• Responsive Design
• Subscription form
• Social Media Posts integration
• Social Media banner
• Auto-localization and blog default language switch to Portuguese and English
• eCommerce to sell my favorite laptop "I survived another meeting that should have been an email" sticker

I can go on and on here because more than 50 ideas were generated in my brainwriting exercise but I don´t want to bother you with all of them. The point here is asking the right questions and prioritizing the features are really important for an Minimum Viable Product (MVP).

Patrick Lencioni was spot on when he said: “If everything is important, then nothing is.” so, to wrap up, take this features prioritization seriously and invest some time criticizing and linking features with the problem you are trying to solve, after all you (and me) don´t want to work double and waste time on features people won´t use!