Product Features & Requirements
Measured by the number of its features
A grossly obese set of requirements
Requirements proliferation
Features and complexity
It's not the features that matter
I'm sorry, I love engineers
Content as value
Intramural brownie points
We optimize what we measure
Chesterton’s Fence
When users never use the features they asked for
Minimum Awesome Product
An Article by Carlos BeneytoUsers are accustomed to a minimum of quality, and they expect that of all new products.
If our product does not [meet basic expectations of quality], people will automatically believe that it is a bad product and they will not take it seriously. It is not what they expect.
Hence my suggestion that the MVP has died and the MAP: Minimum Awesome Product was born.
Time-based analytics
An Article by Ryan SingerAnalytics apps don't tell you much about usage behavior. You might be able to see how many users performed an event, or how many times they did it. But none of the analytics packages out there are good at showing you how often people do things. Are they using to-dos once a week? Every day? Only signing into the app once a month but happily paying for years?
Time matters. You can't understand usage without time.
What happens to user experience in a minimum viable product?
An Article by Ryan Singer"Feature complexity is like surface area and quality of execution is like height. I want a base level of quality execution across all features. Whenever I commit to building or expanding a feature, I'm committing to a baseline of effort on the user experience."
There’s a distinction to make: The set of features you choose to build is one thing. The level you choose to execute at is another. You can decide whether or not to include a feature like ‘reset password’. But if you decide to do it, you should live up to a basic standard of execution on the experience side.
Features can be different sizes with more or less complexity, but quality of experience should be constant across all features. That constant quality of experience is what gives your customers trust. It demonstrates to them that whatever you build, you build well.
August short No. 2: Glass
An Article by Riccardo MoriGlass looks and feels perfectly tailored to my photo sharing needs and expectations. For me it’s even better than pre-Facebook Instagram in the sense that it pushes me to select and share what I think are good photos (same as it happens with Flickr), rather than making me obsess with getting ‘the Instagram shot’ at all costs every day or multiple times in a day. It doesn’t cheapen photography like Instagram has done for years.
That’s why I hope Glass’s founders/developers will resist feature creep. Resist user objections like: I don’t think Glass is offering that much for the subscription price they’re asking. There are a lot of people who will gladly pay for having a cleaner, simpler, focused experience.
Feature parity
An ArticleWhilst Feature Parity often sounds like a reasonable proposition, we have learnt the hard way that people greatly underestimate the effort required, and thus misjudge the choice between this and the other alternatives. For example even just defining the 'as is' scope can be a huge effort, especially for legacy systems that have become core to the business.
Most legacy systems have 'bloated' over time, with many features unused by users (50% according to a 2014 Standish Group report) as new features have been added without the old ones being removed. Workarounds for past bugs and limitations have become 'must have' requirements for current business processes, with the way users work defined as much by the limitations of legacy as anything else. Rebuilding these features is not only waste it also represents a missed opportunity to build what is actually needed today. These systems were often defined 10 or 20 years ago within the constraints of previous generations of technology, it very rarely makes sense to replicate them 'as is'.
Software that nobody wants
An Article by Gandalf HudlowFinding value is the result of enabling individual and group-level discovery attempts. It's not the result of everyone following one leader's gut.
What just happened is a new software product/feature was created that no customer wanted. This happens way too often. In fact, most hyper important software projects that must be done by date certain or else, have deep flaws that cause some variation of this phenomenon, flaws that include:
- Not wanted - Company specified a solution to a problem that customers don't actually have
- No Rarity - Company is pursuing an iKnockoff of existing products. The market already has two scaled competitors with working solutions, customers naturally spend budget on products that are already successful to avoid risk
- Incorrect Packaging - Customers need a website, but the company created an iOS app instead
- Incorrect Pricing - Customers need SaaS pricing, but the company created a shrink wrapped, on-premise solution with CapEx and maintenance agreements instead
Adding is favoured over subtracting in problem solving
A Research PaperHow would you change this structure so that you could put a masonry brick on top of it without crushing the figurine, bearing in mind that each block added costs 10 cents? If you are like most participants in a study reported by Adams et al. in Nature, you would add pillars to better support the roof. But a simpler (and cheaper) solution would be to remove the existing pillar, and let the roof simply rest on the base.
A series of problem-solving experiments reveal that people are more likely to consider solutions that add features than solutions that remove them, even when removing features is more efficient.
Not Just a New Feature; a New Compact
A Fragment by Jorge ArangoMy sense is that Slack’s teams think of themselves as adding ‘features’ to a ‘product,’ instead of as stewards of a place where people work.
Understanding the Kano Model
An Article by Jared SpoolThe horizontal axis represents the investment the organization makes. As investment increases, the organization spends more resources on improving the quality (remember, Noriaka was a quality guy at heart) or adding new capabilities.
The vertical dimension represents the satisfaction of the user, moving from an extreme negative of frustration to an extreme positive of delight. (Neutral satisfaction being neither frustrated nor delighted is in the middle of the axis.)
It’s against the backdrop of these two axes that we see how the Kano Model works. It shows us there are three forces at work, which we can use to predict our users’ satisfaction with the investment we make.
Doing It Right
An Article by Brad FrostDoing it right requires a different pace of working and a much broader thought process than “ok, let’s get this thing out the door.” Which is super tough because most workplaces place a huge emphasis on getting things out the door, and fast. Little agile tickets that are expected to be completed in micro sprints to me seem to be antithetical to doing it right.
The Web is Industrialized and I Helped Industrialize It
An Article by Dave RupertIn our cultural obsession with billionaire entrepreneurs we laud new features more than the maintenance and incrementalism work of making old features better and more accessible. Maintenance looks like red minus signs in the spreadsheet. New features look like green plus signs. New features look better on our LinkedIn profiles. New features have that pizzazz, baby.
When gardening, the building of planters and initial planting is a very short process. The majority of your time is spent nurturing and monitoring growth. I personally feel the struggle between maintainer work and new shiny feature work. I enjoy that new feature smell but I know that my day-to-day is more like a janitor on a boat mopping up someone else’s barf. In terms of metaphors, the gardening metaphor is certainly better, and it acknowledges that design and development still tend to be more creative endeavors.
Yagni
A Definition by Martin FowlerYagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from Extreme Programming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".
Product vs. Feature Teams
An Article by Marty CaganThis article is certain to upset many people.
Cubed
A dry, husky business
Despite the furor over their aggressive unmanliness, clerks, and with them the office, crept silently into the world of nineteenth-century America. Moral philosophers were mostly preoccupied with the clang of industrialization and its satanic mills, and most regarded as negligible the barely audible scratch of pens across ledgers and receipts that characterized the new world of clerical work. It was only a “dry, husky business,” as the narrator of Bartleby had it.
A segment of the enormous file
As office buildings grew taller, and flammability became a problem, steel file cabinets replaced wooden ones – the tall cabinets mimicking the shape of the skyscraper, such that the “file” seemed to be a metaphorical stand-in for the office itself. “Each office within the skyscraper,” C. Wright Mills would argue some years later, “is a segment of the enormous file, a part of the symbolic factory that produces the billion slips of paper that gear modern society into its daily shape.” Aldous Huxley, in his dystopian novel Brave New World, could imagine no more powerful symbol of a totally bureaucratized world than the idea of each person having his or her name on a file.
Taylorism
“In the past the man has been first. In the future the system must be first.” — Fred W. Taylor
Taylorism was a way of thinking that came at the expense of the workers’ own knowledge of their system. Taylor summed up his philosophy thus:
“It is only through enforced standardization of methods, enforced adoption of the best implements and working conditions, and enforced cooperation that this faster work can be assured. And the duty of enforcing the adoption of standard and enforcing this cooperation rests with the management alone.”
The unscripted practices of the old offices would remain, but as a kind of subterfuge: in the future, a leisurely pace wouldn’t be the norm; time would not be given, but stolen.
Divided against itself
By separating knowledge from the basic work process (“the separation of conception from execution,” as Harry Braverman once put it), in the factory as well as the office, the ideology of Taylorism all but ensured a workplace divided against itself, both in space and in practice, with a group of managers controlling how work was done and their workers merely performing that work.
Somewhat more dangerously, this division put into serious doubt the notion that office workers were, as a whole, on the way up. It became increasingly clear from the shape of the offices themselves, and from the distance between the top and the bottom rungs of the “ladder”, that some workers were never going to join the upper layers of management. For some, work was always, frankly, going to suck.
Form follows finance
The formula that Sullivan coined to explain this individualist-conformist principle has become a commonplace of architectural history: “Form follows function.” The envelope of the building was to reflect no particular style, no empty ideal, but rather, with as pure a transparency as possible, the shape and feel of the interior. It was the office that determined the skyscraper – a fact that might have had a beneficial effect on the form of the office itself.
But the result was the opposite: few conceptions of the office have had a more deleterious effect on the human work environment. The title of an influential work by the architectural historian Carol Willis gives us a better, if less palatable, explanation: Form follows Finance. For by and large, making an office “functional” had less to do with making it serve the needs of a particular corporation and much more with serving any corporation. The point was not to make an office building per specification of a given company, but rather to build for an economy in which an organization could move in and out of a space without any difficulty. The space had to be eminently rentable.
Serendipity
This was not meant to be like Bell Labs; there were no expectations that the clerical workers would run into their managers in a “serendipitous encounter” and produce a new innovation. The ideas was rather to create a workplace in which status barriers seemed to dissolve, in which participation and friendliness all around made the work environment look less like the white-collar factory it was.
Office survival
“The caveman was undoubtedly very pleased to find a good cave but he also undoubtedly positioned himself at the entrance looking out. Protect your back but know what is going on outside is a very good rule for survival. It is also a good survival rule for life in offices.” — Robert Propst, The Office: A Facility Based on Chicago
The office landscape
An organic, almost forest-like office layout.
There is an affinity with certain planned “landscapes” of the natural world – namely, the classic Italian Baroque garden. In the sample plans the Schnelle brothers devised, the arrangement of desks seems utterly chaotic, totally unplanned – a mess, like a forest of refrigerator magnets. But, as with the seemingly “wild” overgrowth of a “natural” garden, the office landscape is more thoroughly planned than any symmetrical and orderly arrangement of desks. Imaginary lines wend their way around every cluster, delineating common pools of activity; between and through the undergrowth of clusters are invisible, sinuous paths of work flow.
Open-plan the world
In the end, noise would always be a problem, when quiet was not placed at a premium. Interaction and communication were conceived of as norms in the landscaped office; introspection and concentration were sidelines. In the rush to open-plan the world, some crucial values for the performance of work were lost.
The cubicle
The cubicle had the effect of putting people close enough to each other to create serious social annoyances, but dividing them so that they didn’t actually feel that they were working together. It had all the hazards of privacy and sociability but the benefits of neither. It got so bad that nobody wanted them taken away; even those three walls offered some kind of psychological home, a place one could call one’s own. All these factors could deepen the frenzied solitude of an office worker.
Chilled-out anxiety
Working in the typical dot-com office was an admixture of frenetic pace and a relaxed overall atmosphere, exemplifying that chilled-out anxiety which was the general mood of the 1990’s.
A resource
The office, Chiat argued, had become the site of a turf war, not a place to do work. Changing the office “means focusing on doing great work instead of focusing on agency politics,” he argued. “You come to work because the office is a resource.”