Jason Shah

Product People Need Tech Chops

Product Managers should understand the technology that drives the products we build. After all, an effective product manager has a bold product vision, has the trust of engineers, and makes smart tradeoffs. Each of these is strengthened by understanding the power and limitations of the technologies used to build a product.

Ultimately, I do believe that knowing how to program is the most effective way to understand technical implementation. So these conceptual descriptions are certainly incomplete and imperfect. But they are aimed at simply priming PMs who need the basics to get started.

So here are some concepts (and PM questions!) to get going if you either don’t know how to code or know how to code but need to know which pieces are essential for product management.

Frontend (client-side) / backend (server-side)

Frontend is the look and feel. The languages used: HTML/CSS/Javascript mainly. Backend provides data from a server. The languages used: PHP/Ruby/Python.

Doing more on the client-side tends to be bad because it hurts “performance”, which we will cover next. More on the server (calling a million rows from a database) also isn’t good, but server processing tends to be faster than client-side processing. Why? Generally speaking - web browsers can only be optimized so much. Intense servers that are optimized for data receiving / sending (reading / writing) can process much faster.

PM Question: We need to test what happens when we make our feed more legible. What sort of engineers do we need?

Well, chances are that legibility has to do with font size, line spacing, color schemes, and more frontend changes. This can be done through HTML and CSS. That is front end. The content that is being served up is being handled on the backend. So you may need “one frontend engineer” to implement changes to test a legibility change. But I said “test” - so what if you want to run this as an A/B test? You may need a backend engineer who can manage the treatment sent back to the user from the server and sending data back to a server around how this feature affected the user base. Wikipedia has more on frontend and backend differences.

Performance

Is your application slow? That’s poor performance in a very simple sense. Product managers need to understand performance because it impacts what sort of features you envision, how you consider tradeoffs, and whether you build good products.

For example, imagine you wanted to test a mentioning feature in your product, so your users can reference other users in posts. Typically this updates as the user types. Therefore, it happens “client-side” and needs to perform quickly. Otherwise, there will be a lag and poor performance tends to correlate with reduced engagement and lower conversions.

 

PM Question: What algorithm would you use behind an initial test of a mentioning feature?

My Answer: Alphabetical. The trap here is to suggest some complex relevance algorithm that may, just maybe, work really well. Even better than either a random sort or an alphabetical sort. But the goal here is not perfection. So there’s 2 concepts to keep in mind: MVP and performance.

MVP. Minimum viable product is the smallest, representative version of the feature you’re aiming to build (in this case). Creating a complex algorithm is not small. Alphabetical sorting is, especially because this is a long-standing, built-in technical function. For MVP, iterative development and building smaller things is better, so you can course-correct more easily.

Performance. Without being technical, one may believe all algorithms are created equal. That computers “just do it.” But when it comes to performance, think of computers more like humans. They have to *do* things. Get the members, fetch the relevance inputs that the crazy PM devised, calculate relevance for each member, render that sort back to the client, etc. Your mentioning feature will be very slow compared to “Fetch the members and sort them A-Z.” Imagine if someone asked you to put your pants and shirts in two different piles. Then what if they asked you to also sort each of those individual piles by color, size, and material. You probably would be much slower with that second task than the first task. This is be the difference between a snappy, 0.2 milliseconds load, vs. a 2,000 millisecond (2 second) load.

Databases and Tables

A database is simply a place where information lives. You store tables in a database and the tables contain rows and columns of information you define. Imagine a Google Doc with rows and columns for you to read from and write information to. That’s a table. Usernames and hashed passwords. Locations of media files corresponding to profile pictures. Raw information that you need to serve back to users. These pieces of information live in tables.

The database (and its tables) lives on a server somewhere, so it will not be “client-side”. Imagine having to access millions of rows of information - you couldn’t possibly load that whole thing into the webpage every time you needed to just look up one tiny bit of info. But you could fetch the single piece of info from the table through a SQL query or something like that and then that one small, relevant piece is delivered to the client. It would also be a security risk to send back data that should not be accessible to the user trying to access your site (e.g. other users’ data).

Clients

“Clients” refers to the channels through which the application is accessed (the website or mobile app is used). So, there’s the web client, the desktop client, the iOS client, the Android client, and so on. However, a “clients” team often focuses on all of the non-web client work because so many companies have web-first products, even in our now mobile-first trend. Sometimes “platform” is used interchangeably with “client” in marketing-speak, i.e. “We are cross-platform.”

Native

Native applications are those developed for use specifically for that platform. Native iPhone apps have to be written in Objective C for example. But a hybrid app that uses webviews, or an app that is a mobile web app, can get away with using web technologies like HTML/CSS/JS that work across platforms. Early stage startups sometimes develop mobile web apps because it allows them to be cross-platform faster. But as we saw with Facebook before they went fully native, this can lead to a degraded experience because you are not “as close” to the processes of the device and have to go through the web browser instead.

Plugins

Code is often like a puzzle. If you have a puzzle and it’s missing a piece, you can’t complete the puzzle of the cute zoo animal. If you have not defined a function, but attempt to use that function in your code, it won’t work. It’s like trying to use a word in a sentence when that word does not exist - no one will understand you. Similarly, computers will not understand your code if you do not have the underlying code, the function, to make it work.

Plugins are simply extra pieces to the puzzle. Don’t want to reinvent the wheel for fancy mobile carousels? There’s a plugin for that. Don’t want to figure out grids and make buttons from scratch for your application? There’s a framework - namely Twitter Bootstrap - for that.

Related terms to “plugins” are templates, frameworks, and libraries. They are all somewhat different, but in conversation, they are sometimes used interchangeably.

Open Source

Open source can be your best and worst friend. If you are at a small startup, open source means that there is a public solution for a problem you are trying to solve. If you are a big company, this means you probably can’t use the solution because your legal department will shut you down and tell you can’t use it. In short, their argument is probably along the lines that the liability of using 3rd party intellectual property outweighs any engineering benefit you think you may get. They may be wrong, but you will lose the argument, so move on. The point is to be aware of whether the company you’re interviewing with will be receptive or not to open source solutions.

PM Question: We just built a cutting-edge framework for conversations. Now you don’t have to build your own reply/like/share functionality and design if you are building a social network or other product that has conversations. Should we open source it?

My Answer: There’s not an obvious right answer. This also isn’t often something asked of PMs, but a PM at an early stage company may weigh in on this and should at least be able to have an opinion on it. Competitively, if we open source this, it reduces the cost for a new startup trying to disrupt us. But is it really hard to build conversation structures anyway? Maybe not, and how disruptive could they be if they just copy our conversation structure? This positions as ‘experts’ of sorts since we took our solution and made a standard of sorts. Again, this isn’t really something that is asked of PMs, but the ability to think through tradeoffs in a technical and business frame is indeed important.

APIs

Application programming interface. To me, APIs are just a way for systems to talk to each other. Want your app to use Yammer’s user data? Use our secure API, so you can enhance your app the posts that your users have already made in Yammer — provided your users supply the necessary user authentication credentials. Want to post to people’s Facebook walls when they complete a run with your fitness app? You need to talk to the Facebook system, check that user’s login credentials, and then pipe your content through Facebook’s pipes. Here’s some more info on APIs.

PM Question: We want to build a product that shows people where in their neighborhoods they can purchase certain items. Can we do this with APIs and if so, which should we use?

My Answer: Yes, this can be built on top of existing APIs. For location, you probably want to use the Google Maps API. You could also consider the Foursquare API or the Locu API, which are primarily focused on information about local businesses. For purchasing items, think creatively. Which marketplaces exist? Craigslist. Well, they don’t have an official API. Presumably their data is their most valuable asset, and exporting it elsewhere would diminish visits to Craigslist.com and their advertising revenue. When a site doesn’t have an official API, people resort to web scraping, but this isn’t usually legal or acceptable. No wonder apps built on top of Craiglist often get shut down.

But back to the question - marketplaces. Milo.com - they help people find products locally and have a basic API. Or eBay’s API. But a question will be whether these APIs have geography info. Without it, you won’t have coordinates, zip codes, or anything else to pass to the Google Maps API to put pins where products are. Google Maps can draw pins on locations when provided with the info for that location and what the hovercard should contain for it. But it probably cannot supply a latitude/longitude if you feed it, say, an eBay username. That’s not what it is for. These are the sort of questions that a PM who understands APIs can reason through on a basic level.

Other Vocab

Tech Stack - all of the technologies that power your product. Imagine an actual stack with layers

Velocity - not dissimilar from the generic term, velocity is about engineering moving quickly to ship new code, features, etc.

Agile - related to velocity. Shipping small features quickly.

Summing Up

Product Managers often have varying technical abilities, especially at different companies. Google PMs tend to be more technical than say, Facebook PMs. But product management is like being the quarterback in American football. But how can a good quarterback appreciate how little time he has to throw the ball if she has never been on the frontlines to block for the quarterback? How can she understand how important a good spiral is if she has never had to catch a poorly thrown ball?

Understanding the challenges of your teammates is key to being a good leader, and hopefully these tips will help you work with your team.

Additional Resources

Programming for Non-Programmers (Chris Castiglione @ GA)

10 Tech Concepts Everyone Should Know (Benjy Weinberger @ Foursquare)

CS for Managers (David Lifson)

Flat Iron School Pre-Work (h/t Melissa Tsang for the find; authors for the content) 

Tweet Follow @jasonyogeshshah
Vote on HN

$3 coffee makes little obvious economic sense. $20 makes even less. But people pay for experiences, and your product should factor in what people are really buying. Companies often charge for value that they may not even provide, but rather, value that they facilitate access to.

 

Take this coffee shop (on the right, behind the tree) in Hayes Valley, San Francisco. To the left are sun-soaked chairs and benches where people hang out.

The uncreative, cost-based pricing model charges for coffee beans, cups, lids, sleeves, real estate, and labor. The value-based pricing model charges for sunlight, time with loved ones, a pleasant memory, and whatever other intangibles you may enjoy over that cup o’ joe.

I don’t know if anyone would pay $20 for the same coffee that today they pay $3 for. But since we’re already paying for the experience and not the materials, why not?

Tweet Follow @jasonyogeshshah
Vote on HN

Here is a list of useful resources for prospective and current PMs. Some are for novices, some for experts. Enjoy and suggest new ones in the comment section below!

What is Product Management (The Daily Muse)

“Do you often catch yourself starting sentences with, “If I designed this product, it would be better because…?” As a product manager, you make decisions across every stage of a product’s lifecycle, from its initial planning, design, and development all the way to marketing and launch. You determine what features a product should have, what order to build them in, and when to launch them. Then, you turn your big-picture ideas into a concrete, step-by-step action plan and manage it to completion, keeping everyone involved—from designers to developers to the marketing team—on the same page and in sync.”

The Art of Product Management (Notes from Product SF 2013 written by Ian Kennedy)

“PMs need to be entrepreneurs. Faced with a limited amount of resources, you need do whatever it takes to get things done. This often means you need to think creatively. Hunter also mentioned “learning to draft ascending ecosystems” – take an objective look at the market and if there is a way for you to bundle or integrate your product into another product on the rise. By focusing on getting the YouTube icon added to the default iPhone deck, all other conversations with carriers turned from YouTube chasing them to the carriers calling YouTube. Picking the ascending leader early was a bet that paid off.” 

What I Look for in a Product Manager (Dave Lifson)

Lots of people have asked me how I define the role of a product manager, and, since there is so much variation, I thought I’d share my thoughts. Every company is different, but for companies that are similar to Amazon’s “2 pizza team” concept (1 tech/biz manager + 1 PM + 1 designer + 2-8 engineers operating independently of other teams in the pursuit of a particular goal), this should work.

How to Hire a Product Manager, Ken Norton

Product management may be the one job that the organization would get along fine without (at least for a good while). Without engineers, nothing would get built. Without sales people, nothing is sold. Without designers, the product looks like crap. But in a world without PMs, everyone simply fills in the gap and goes on with their lives. It’s important to remember that - as a PM, you’re expendable. Now, in the long run great product management usually makes the difference between winning and losing, but you have to prove it. Product management also combines elements of lots of other specialties - engineering, design, marketing, sales, business development. Product management is a weird discipline full of oddballs and rejects that never quite fit in anywhere else. For my part, I loved the technical challenges of engineering but despised the coding. I liked solving problems, but I hated having other people tell me what to do. I wanted to be a part of the strategic decisions, I wanted to own the product. Marketing appealed to my creativity, but I knew I’d dislike being too far away from the technology. Engineers respected me, but knew my heart was elsewhere and generally thought I was too “marketing-ish.” People like me naturally gravitate to product management.

 

What Distinguishes the Top 1% of Product Managers from the Top 10%?

The top 10% of product managers excel at a few of these things. The top 1% excel at most or all of them:

• Think big - A 1% PM’s thinking won’t be constrained by the resources available to them today or today’s market environment. They’ll describe large disruptive opportunities, and develop concrete plans for how to take advantage of them.

• Communicate - A 1% PM can make a case that is impossible to refute or ignore. They’ll use data appropriately, when available, but they’ll also tap into other biases, beliefs, and triggers that can convince the powers that be to part with headcount, money, or other resources and then get out of the way.

• Simplify - A 1% PM knows how to get 80% of the value out of any feature or project with 20% of the effort. They do so repeatedly, launching more and achieving compounding effects for the product or business.

• Prioritize - A 1% PM knows how to sequence projects. They balance quick wins vs. platform investments appropriately. They balance offense and defense projects appropriately. Offense projects are ones that grow the business. Defense projects are ones that protect and remove drag on the business (operations, reducing technical debt, fixing bugs, etc.).

  [and more…]

Why Did Infinite Scroll Fail at Etsy? (added 5/9/13)

A tale of building a feature beyond MVP and the consequences. Original talk here.

—

This will be a living list that I’ll update from time to time. Any suggestions on resources to add or comments on these?

Tweet Follow @jasonyogeshshah
Vote on HN

This will (hopefully) grow to be a full, useful list:

How to Influence People and Win Them Over http://www.4hb.com/08iceinfuencepeople.html

Tweet Follow @jasonyogeshshah
Vote on HN

Earlier this month, I attended The Gov Lab Experiment. Led by co-founders Beth Noveck, Manik Suri, Aaron Cohen, Director of Research Stefaan Verhulst, and an army of changemakers in New York, The Governance Lab at NYU “designs more open, effective and networked institutions to improve the quality of people’s lives”.

This event brought together 100+ leaders from government and technology. We had 6 sessions focused on problem areas like “Identifying Experts” and “Asking the Right Question”.  These 6 sessions of ~20 people eventually each broke into smaller teams to actually envision and build solutions to the problems that government folks were raising. By 4pm on day one of two, most teams were prototyping, and by the next morning, many teams had hacked together either a series of mockups or functioning products. Some of them were:

• CareShare - choose what kind of medical specialist you need and CareShare will tell you what’s near and how well each hospital performs. It will also let you review individual doctors.

• City Mission provides tools for people to ask questions about the city and collect data together.

• ReallyVote lets you easily communicate thoughts with elected representatives by giving people quick access to the right congressional Twitter accounts.

• Govrn allows local, state and federal governments to directly engage and question their constituents in real time.

Here are three surprising ideas I learned from my time during The Gov Lab Experiment:

Pairing up influential government leaders with competent technologists gets products built, and actually used. One without the other is often an incomplete equation for problems that need government participation for resolution.

It seemed like government folks leaned towards forming committees instead of building prototypes, and technologists wanted to hack away immediately, often missing nuances of the core issues.

But just as technical and business co-founders complement each other in technology startups, the complementary value of government leaders and technologists is undeniable. Pairing government folks, who have countless vivid use cases to share and powerful (virtually monopolistic) distribution channels, with technologists who can ship code overnight that a government committee might otherwise discuss for three years, is a potent combination and a leap forward in how we solve civic issues. It is one of the most meaningful examples of interdisciplinary partnership. We began to see this force at work as jargon-driven sessions faded away into the breakout sessions and people finally got to translating conversation into code.

If we can increase the communication between people setting policies and people building products, and make it easier for developers to access government distribution channels to promote good, perhaps private, technology solutions, the better off we will be in my view.

Technology and data need to be used to refine solutions that academics / government leaders are aiming to craft with inquiry devoid of actual user behavior.

One session I joined spent hours of just a two day conference attempting to refine an admittedly complex problem.

Participants debated what was most important for the session’s protagonist: Finding subject matter experts? Knowing which is the right expert for your specific problem? Reconciling what the various experts say? Identifying operators who can execute on whatever decision the experts propose? Building consensus around whichever decision your government makes?

Indeed, these are important questions to answer. But at data-driven technology startups, we answer questions differently: not through inquiry, but through experimentation. It’s not by asking the user what they want or what they think their problem is. It’s through data that we become enlightened. We realize that our understanding of problems, and the solutions we imagine, are rarely correct straight out of the gate. That’s why building three-year cycles or longer would spell death in a competitive market. We build a “minimum viable product” and monitor data about how people use the service to determine whether it was a good solution and what to build next. Users don’t know what they need. But the data about how people use a product will tell you whether you’re solving a problem, and in the right way or not.

Perhaps in government you only get a couple shots to get it right, and the risks are often higher, so this experimentation-oriented methodology may seem poorly suited. But people said the same in the software industry, and that mentality collapsed. I believe an experiment-over-inquiry methodology will be the future across industries and governance.

One could spend all day talking back and forth about what *might* be the core problem and what the user *thinks* the solution should look like. We cannot allow anyone — the government leaders who aren’t technologists, or technologists who are not government folks — to overrule data in shaping the product’s development.

For example, before 311 emerged, one could debate whether anyone would use it. Which government programs it should plug into. Whether making complaints was more important functionality than filing for licenses. Sure, you could convene a committee to prioritize, or you could survey all the citizens for a few months. But you could also just hack an MVP (“minimum viable product”), measure what people use, and build new features based on the behaviors that people actually demonstrate.

This is the Ivy Tower problem, now met with a Silicon Valley attitude.

Getting more people, especially developers, simply to be aware, and invested in, improving governance is a still-untapped source of innovation.

Since walking away from The Gov Lab Experiment last week, I have talked to dozens of people about the role of tech in improving governance and more. I have started hacking on a new civic tech project for fun. I have a hard time hearing about some new legislation or civic problem without thinking about products that may be the answer. I was barely interested in civic tech before.

To be clear, not every problem is a technology problem. Not everything can, or should, be productized.

But from my experience, developers and startups can disrupt most any industry they set their eyes on. Napster, and now Pandora/Spotify are doing it to music. Paypal, and now Square/Stripe, are doing it to payments. The web, and specifically Facebook/Twitter, are doing it to the media industry along with an array of other industries all at once. Yet developers appear to have been relatively quiet in government.

It’s not because government is hard to disrupt: every industry is hard to disrupt.

It’s not because it’s not lucrative: government contracts and getting a whole city or country to use an application would be more lucrative than a lot of other markets.

It’s not because hacking government isn’t appealing: developers love making impact.

So, simply getting and keeping developers engaged in civic tech is limitlessly powerful.

—

That’s why events like The Gov Lab Experiment and others like it are so important. Just promoting the governance idea to people who are actively building solutions that would otherwise be in other industries and spaces will keep it top of mind. So when these technologists interact with governance bodies and civic systems on a daily basis, building solutions will feel more in reach and are more likely to materialize as opposed to another social networking app. Moreover, supporting people from the two disciplines to coordinate better and learn from each other’s methodologies can only accelerate the rate of change in civic tech.

-

(If you would like to get involved with The Gov Lab or hack with me on some gov 2.0 projects, let me know).

Tweet Follow @jasonyogeshshah
Vote on HN

During my education and social experiences (i.e. my life thus far), I have developed a behavior I would like to unlearn: signaling completion for the sake of validation.

This morning, a friend shared a post with me. He knew I would upvote it on Hacker News. There was literally no need for me to signal that I had in fact upvoted it. But, I am used to telling people that I have done something even when they will know that I did anyway when the result reaches them or because we had an understanding beforehand.

Another example is when I introduce people. Both people will get the introduction email. Yet, I still often go back to the email thread that requested the intro, and let the original person know. Sure, sometimes there’s other stuff in that email, or it’s a nudge for the junior person to follow up with the senior person. Or it’s just a courtesy. But often it’s not. I just want them to say thanks, again, or somehow acknowledge what’s been done. Or a pat on the back saying, “Good job ol’ boy”.

It’s a silly habit. It generally is a waste of time, but people who did well in school or who enjoyed the rewards of school, seek validation out in many forms…

Promotions with no change in role or compensation - just title. 

Media coverage that doesn’t do anything meaningful for the business.

And so on.

Eliminating this behavior (pointless calls for validation) saves time and will wean one off of external validation, which is often a red herring that distracts from meaningful progress.

(I am not sure if I agree with, or have baked, everything I’m even saying here, but maybe it will be a launching point for a productive conversation, or not. Let me know if you disagree.).

Tweet Follow @jasonyogeshshah
Vote on HN

Blogging Takes Persistence. My first 13 posts got 4 or less upvotes, never making the front page. It’s a year later. Today’s post on Foursquare has gotten 50 upvotes and more than 3,000 page views so far today.

Foursquare just announced an additional $41m in funding. Many believe this to be the company’s last major chance to show it can build a large business on the back of a successful consumer app with some inroads into SMBs and large brands alike.

Let me begin by saying, I am not trying to be a troll or hater. Promise. I want this to be a constructive conversation. With so many people building consumer apps, and often delaying “the revenue conversation”, understanding the connection between building (and sustaining, if not growing) a product hook and growing revenue needs to be fleshed out.

I want to be excited for them. But from a purely critical standpoint, I have a hard time seeing them pull this off. They are building a business that is orthogonal to what I believe is the core user behavior. That’s dangerous.

Emphasis on Friends and Check-Ins: Ditched for Promoting Local Businesses…a fatal attempt at making an app into a business

This is actually a huge product pivot. People came to Foursquare before for different reasons than *discovering* new businesses. Checkins. Meet people. But now…the focus is on pushing me to go to a local pastry shop to save 50%, max $5 — on something I didn’t want before? By contrast, Yelp has always been focused on the best — if it’s 5 stars and you say you want something close, you’ll see the best possible matches even if those results are preceded by a promoted restaurant (same way Google does it).

But now Foursquare is an ads business. When I say “ads”, I mean local promotions and beyond. They are already doing this (see the above screenshot). So, there’s not really a debate IMO about whether they are an ads business today. Maybe they can have multiple revenue streams in the way that Linkedin has done, but arguing about whether Foursquare is an advertising company, at least right now, is a red herring that distracts from the core argument here.

Generating and Harvesting Purchasing Intent Will Not Work without a Core Product Hook

Google Ads work because they just harvest intent. “You want (you search for) something? OK here are some businesses that can sell you that.” That’s relatively easy and gives the users what they wanted in the first place. Typing a search is an easy hook and has been increasingly adopted over time. Now that behavior is ubiquitous. It has evolved (search from browser address bars, speak-to-search, etc.) but remained easy, engaging, and ubiquitous.

Another easy product hook is posting an update on Facebook or Twitter: lightweight and it has opportunities to create engagement loops when people Like, reply to, retweet, share, or do anything else with your content.

The key problem here is the Foursquare is attempting to generate AND harvest demand without a product hook (checkins have been taken away by competitors building better, focused experiences). No one wanted a pastry. I sure didn’t. Pastries are irrelevant to me right now and most times. But this is the new product emphasis built on top of a product hook (check-ins) with evaporating utility in the Foursquare ecosystem. Check-ins are moving to Facebook, Path, etc., so now Foursquare is left with local promotions but no core utility for the user.

Facebook can get away with generating and harvesting intent for a few reasons that don’t work for Foursquare.

1. (Un)targeted demand generation: Facebook can target who it generates intent for. Showing pastries to me is irrelevant. But showing me ads for analytics services, ridesharing apps, and more…is not. Advertisers can be very targeted on Facebook. Foursquare - with just basic information about me - can’t do the same frighteningly good job of targeting who they target in order to generate demand. Untargeted demand generation is resource intensive and converts poorly. In a world of hyper-targeting, Foursquare’s geodata and basic demographics are close to “untargeted”.

2. Scale: Even if Facebook ads convert poorly, the sheer number of users and amount of engagement they register with the product (pageviews on Facebook vs. loads of the Foursquare app are different orders of magnitude) gives Facebook more opportunities to generate and harvest intent such that it can compensate for the low CTR that people complain about.

3. Fulfillment Friction: Foursquare is an example of an online solution powering offline commerce. That’s bold, so I respect it. But even if I am walking around my neighborhood, if I go to the pastry place Foursquare recommends, I have to a) walk there, even if it’s close b) convince whomever I am with to go with me. On the other hand, Facebook just needs me to either load a page (frictionless, since I am doing that anyway to enjoy their core product) or make one click — depending on if an advertiser is running a CPM or CPC campaign. Foursquare fulfillment of promotions is very difficult to drive conversions for. I am sure there is a big drop off between the offers viewed and those redeemed.

Therefore, there is a clear misalignment between the value that Foursquare aims to deliver and what their users want. It’s like intentionally foregoing product market fit in an attempt to squeeze some revenue out of a minority of users. I don’t blame them because they were already seeing corroding product-market fit with a check-in product in a world in which check-ins alone don’t suffice due to changing consumer behavior. That’s not to mention increasing competition through Facebook, Path, and Highlight-type of apps — each with a different spin on check-ins that took away chunks of Foursquare users better served by those individual apps.

I hope Foursquare proves me wrong. They are pirates, in the game, trying to make something big happen. I respect that, and don’t want to “be a hater”.  I used to be a user of their app. I have no doubt they can have a large exit even if they don’t pull this move off. But I don’t see them building a large independent business when their core product hook is both corroding and orthogonal to how they generate revenue — and that should be a lesson to others building large consumer apps that aim to be large consumer or B2C2B businesses one day.

—

This has picked up on Hacker News. Discuss here https://news.ycombinator.com/item?id=5532680. Also Jason Baptiste makes some good counterpoints in a separate post made today.

Tweet Follow @jasonyogeshshah
Vote on HN

Elements like rounded buttons and menus with expandable content have made it into web apps everywhere. New design elements and interactions tend to spread fast. But over time, no one really questions why they are the way they are. Similarly, people don’t appreciate the value they deliver and remember how the interaction was before. This hinders our ability to rethink interfaces and advance user experiences at a faster pace.

As an analogy, people also forget that suitcases didn’t always have wheels on them. Not until 1970.

Isn’t this so much better:

While I’m not a fan of most of PayPal’s design, I’ll give them an easy layup on good UX here by appreciating their use of a dropdown menu.

Use Case: Person would like to withdraw money from PayPal.

UX Problem: There are at least 3 sources for that withdrawal to be deposited into: 1. Bank Account 2. Check 3. PayPal Debit Card. This affects the user flow. But loading a brand new page just to select which of these choices a person wants increases friction: new page load, changes view, takes time, disorients a user, etc.

(Side note: It also requires designing, building, and maintaining a whole new page. This is bad for the user experience and expensive for the design/engineering teams.)

UX Solution: Allow a user to semi-actively indicate the need to withdraw money without clicking and changing the view. Hover is lighter than a click. Then show the options in place and the user can choose one with a click. Avoid the page change. Have this occur without the options disappearing when the user mouses away from the original target into the drop-down options since they are likely to mouse down into the options.

—

These dropdowns are everywhere today and well covered (Smashing Magazine post), but it’s nice to appreciate the fundamental problem they solve. It also helps us brainstorm newer solutions. For example, maybe one day you won’t even click on the dropdown options but rather hover over those, too. This would reduce the cost of the physical action needed to express intent (hovers are lighter than clicks). Of course, the chances of mis-hovers goes up with a solution like this, but it’s a single example as a thought exercise. 

Svbtle uses this interaction well (hovers for action), and since the element is not a drop-down, there’s no risk of mis-hovers.

 

Or maybe in the future you can enter the amount to withdraw / submit the request from the dropdown and *never* change views. Maybe the whole website becomes just a webpage.

Anyway…next time you use a drop-down menu, hopefully you remember how much time and hassle it saves. And maybe you can invent the next UX interaction that will make everyone’s lives better.

Tweet Follow @jasonyogeshshah
Vote on HN

Recently I was reading an article in The Economist on my phone. Articles are increasingly consumed within in-app web browsers. It’s important for media outlets to brand themselves well in this new medium.

As I scrolled, as readers tend to do through articles, I couldn’t help but notice the bright red, sticky logo of The Economist.

Later, when I wanted to mention this article, you can be sure that I knew where I had read it: The Economist.

Sticky headers. Noticeable logos. It matters. Especially in a world of undifferentiated forms of media consumptions (link shorteners often obscure your brand, articles are read as one-offs through social media vs. in your magazine next to all of your other articles, etc.)

Contrast how The Economist does this to how, of all sources, a technology blog: Pandodaily.

 

 

Had Twitter’s web browser not displayed the URL at the top of the page, you wouldn’t even be able to *figure out* that Pandodaily was the source, let alone have an easy brand association form naturally.

Content providers that don’t implement various branding tactics for the new mobile world - like sticky headers - are missing out on important opportunities to associate themselves with otherwise memorable moments.

Tweet Follow @jasonyogeshshah
Vote on HN