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.
The Image of the City
- To become completely lost
- Apparency
- On the edge of something else
- Nothing there, after all
- Paths, edges, districts, nodes, landmarks
To become completely lost
To become completely lost is perhaps a rather rare experience for most people in the modern city. We are supported by the presence of others and by special way-finding devices: maps, street numbers, route signs, bus placards. But let the mishap of disorientation once occur, and the sense of anxiety and even terror that accompanies it reveals to us how closely it is linked to our sense of balance and well-being. The very word "lost" in our language means much more than simple geographical uncertainty; it carries overtones of utter disaster.
Apparency
Half a century ago, Stern discussed this attribute of an artistic object and called it apparency. While art is not limited to this single end, he felt that one of its two basic functions was "to create images which by clarity and harmony of form fulfill the need for vividly comprehensible appearance." In his mind, this was an essential first step toward the expression of inner meaning.
On the edge of something else
The most common response to the question of symbolism was nothing in the city at all, but rather the sight of the New York City skyline across the river. Much of the characteristic feeling for Jersey City seemed to be that it was a place on the edge of something else.
Nothing there, after all
When asked to describe or symbolize the city as a whole, the subjects used certain standard words: "spread out", "spacious", "formless", "without centers". Los Angeles seemed to be hard to envision or conceptualize as a whole. Said one subject:
It's as if you were going somewhere for a long time, and when you got there you discovered there was nothing there, after all.
Paths, edges, districts, nodes, landmarks
The contents of the city's images which are referable to physical forms can conveniently be classified into five types of elements: paths, edges, districts, nodes, and landmarks.
- Paths are the channels along which the observer customarily, occasionally, or potentially moved.
- Edges are the linear elements not used or considered as paths by the observer. They are the boundaries.
- Districts are the medium-to-large sections of the city, conceived of as having two-dimensional extent.
- Nodes are points, the strategic spots in a city into which an observer can enter, and which are the intensive foci to and from which they are traveling.
- Landmarks are another type of point-reference, but in this case the observer does not enter within them, they are external. They are usually a rather simply defined physical object: building, sign, store, or mountain.
A directional quality
Paths may not only be identifiable and continuous, but have directional quality as well: one direction along the line can easily be distinguished from the reverse. This can be done by a gradient, a regular change in some quality which is cumulative in one direction.
Introverts and extroverts
Some regions are introvert, turned in upon themselves with little reference to the city outside them, such as Boston's North End or Chinatown. Others may be extrovert, turned outward and connected to surrounding elements. The common visibly touches neighboring regions, despite its inner path confusions.
Junctions
The junction, or place of a break in transportation, has compelling importance for the city observer. Because decisions must be made at junctions, people heighten their attention at such place and perceive elements with more than normal clarity. This tendency was confirmed so repeatedly that elements located at junctions may automatically be assumed to derive special prominence from their location.
What we are accustomed to call beautiful
Most objects which we are accustomed to call beautiful, such as a painting or a tree, are single-purpose things, in which, through long development or the impress of one will, there is an intimate, visible linkage from fine detail to total structure.
A certain plasticity
There are dangers in a highly specialized visible form; there is a need for a certain plasticity in the perceptual environment. If there is only one dominant path to a destination, a few sacred focal points, or an ironclad set of rigidly separated regions, then there is only one way to image the city without considerable strain. This one may suit neither the needs of all people, nor even the needs of one person as they vary from time to time. An unusual trip becomes awkward or dangerous; interpersonal relations may tend to compartmentalize themselves; the scene becomes monotonous or restrictive.
As plain as day
The personal experience of most of us will testify to this persistence of an illusory image long after its inadequacy is conceptually realized. We stare into the jungle and see only the sunlight on the green leaves, but a warning noise tells us that an animal is hidden there. The observer then learns to interpret the scene by singling out "give-away" clues and by reweighting previous signals. The camouflaged animal may now be picked up by the reflection of its eyes. Finally by repeated experience the entire pattern of perception is changed, and the observer need no longer consciously search for give-aways, or add new data to an old framework. They have achieved an image which will operate successfully in the new situation, seeming natural and right. Quite suddenly the hidden animal appears among the leaves, "as plain as day."