Menu

The social media lives of teens

Mary Choi’s Wired feature on the social media lives of teens is utterly fascinating. I don’t even know where to begin. Let’s start with this bit from Like. Flirt. Ghost: A Journey Into the Social Media Lives of Teens:

Then there is the rule about likes and comments. According to Lara and Sofia, when your friend posts a selfie on Instagram, there’s a tacit social obligation to like it, and depending on how close you are, you may need to comment. The safest option, especially on a friend’s selfie, is the emoji with the heart eyes. Or a simple “so cute” or “so pretty.” It’s too much work to do anything else. If there’s any deviation, “you have to interpret the comment,” Sofia says. “If it’s nice, you’re like, is this really nice or are you …” “… I don’t know,” finishes Lara. Is the comment sincere? Or slyly sarcastic? Formulaic responses breed zero confusion. Instagram is not a place for tone or irony.

The whole article is full of examples like this that just makes me wonder how complicated it must be to be a teen right now. Of course, it’s not complicated to them, it just seems that way to us old folk. But seriously:

But back to the ladies. After a few mutual photo likes, the flirtation often escalates to emoji. If an emoji with the heart eyes gets another one in return, he says, you’re good. Other positive responses: an ellipsis thought-bubble to convey that she’s thinking about you; the bashful see-no-evil monkey. “‘Oh, thank you! I appreciate it’ is what I get from that emoji,” he says. Any of these responses means he’ll take it to DM (as in direct message). Other emoji are suboptimal. “The thinky face is like, ‘What are you doing commenting on my pictures?’” He says this isn’t a hard no, but it’s not great. The worst emoji—easily—is one you may not expect. “The smiley face,” says Ahmad with a pained expression. “Yeah, that’s the ‘Thank you, but I’m not interested.’”

I did do quite a double-take when I read this though:

Ubakum loves her [Android] phone. Deeply. iPhones for her are too easy, a little basic. “I’m not a fan of user-friendliness.”

I don’t really know what to make of that. It’s a fascinating statement, and I wish I could follow up to understand the sentiment more. If it’s true that a new generation of users don’t want products to be easy to use, what does that mean for us as designers? My head hurts.

Moving beyond Agile

Andy Budd asks, Are we moving towards a post-Agile age?

Perhaps we’re moving towards a post-Agile world? A world that is informed by the spirit of Agile, but has much more flexibility and nuance built in.

This post-Agile world draws upon the best elements of Agile, while ditching the dogma. It also draws upon the best elements of Design Thinking and even — God forbid — the dreaded Waterfall process.

People working in a post-Agile way don’t care which canon an idea comes from, as long as it works. The post-Agile practitioner cherrypicks from the best tools available, rather than sticking with a rigid framework. Post-Agile is less of a philosophy and more of a toolkit that has been built up over years of practice.

This is certainly true for how our team works as well. We took the parts we like about Agile (like autonomous teams, flexible roadmaps, daily standups, small pieces of work), left out the parts we don’t like (like rigid sprints, long backlog grooming meetings), and then mixed in some spicy goodness from other methodologies (like deploying whenever a feature is ready). I’m sure strict Agile works for some teams — particularly in large organizations — but this approach works much better for us. It speeds us up and makes us all much happier human beings.

Product Management is, at its core, a multi-tasking role

Giff Constable writes about The difference between design and product management and makes this good point about the nature of the PM role:

A big difference is where they spend their time. You’ll hear me call design and engineering “deep dive” roles, while PM is a multi-tasking role, which is why it is relatively easier for PMs to assume more of a leadership role. Even though we work in very collaborative ways (“rough draft culture”) at Axial, both design and engineering require getting into a “flow state” on a problem. Design takes a lot of iteration and trial and error to get something right. PMs, on the other hand, are bouncing around a million tasks, from clarifying a user story, to managing communication inside and outside the organization, to doing whatever it takes to un-bottleneck the team, to all the things listed above.

This is one of the things that makes Product Management such a challenging role. It’s not just about switching tasks, it’s about developing the ability to switch focus really quickly as well. There is no time to meander from one task to the next. Once you switch to the next thing you have to be in it right away.

Facebook as political platform

This NYT report on the massive political news force Facebook has become is quite something. From John Herrman’s article Inside Facebook’s (Totally Insane, Unintentionally Gigantic, Hyperpartisan) Political-Media Machine:

But truly Facebook-native political pages have begun to create and refine a new approach to political news: cherry-picking and reconstituting the most effective tactics and tropes from activism, advocacy and journalism into a potent new mixture. This strange new class of media organization slots seamlessly into the news feed and is especially notable in what it asks, or doesn’t ask, of its readers. The point is not to get them to click on more stories or to engage further with a brand. The point is to get them to share the post that’s right in front of them. Everything else is secondary.

This is the crux of the matter:

Such news exists primarily within users’ feeds, its authorship obscured, its provenance unclear, its veracity questionable. It exists so far outside the normal channels of news production and distribution that its claims will go unchallenged.

The perils of a lack of diversity in urban design

Diana Budds does some great reporting in How Urban Design Perpetuates Racial Inequality — And What We Can Do About It. It’s startling to see how deeply ingrained racism is in the way cities are designed. One of the most effective ways to change this? Diversity and immersion in the needs of users…

Justin Moore, an architecture professor at Columbia University, believes that while designers focus on creative solutions for urban problems, issues that are rarely broached are shortfalls within the profession, like diversity, a deep understanding of the communities in which they’re building, and the methodology of design education.

”There is a need to redesign the designers, and to give them the tools and competencies to work within social constructs and spatial contexts that they are meant to serve. Designers spend much of their academic and professional training to build the spatial, technical, communication, and critical-thinking skills that are needed to do the difficult work of transforming spaces and places. They use their skills, often with good intentions and ‘best practices,’ toward results that may not align with what is needed or wanted in a given context.

Focus on product instead of technology

Laurent-Pierre Baculard makes some great points in WhatsApp Grew to One Billion Users by Focusing on Product, Not Technology:

Examples such as WhatsApp demonstrate that real-world innovation, in many ways, looks like an assembly line. At one end is a customer pain point or a potential new market. At the other is a product or service that solves the problem or addresses the market in a way nobody has thought of before. In between, people sit down and force themselves to examine the problem from a variety of fresh angles. Sometimes they tap the lab and bring a radical new technology to bear. But much more often they reach for pieces of technology that already exist and assemble them with new (or old) capabilities to produce a solution that turns the pain point into a delighted customer. Think of it as high concept meets whatever is lying around — an unconventional combination.

The problem comes when we reach for technologies that seem “cool” but can’t actually be linked to any real customer problem.

Yes, after a long break I’m giving the blog another shot. Let’s see how it goes…

Product Managers are not “mini-CEOs”

I enjoyed answering some questions about prototyping and Product Management in startups from the nice folks at Justinmind recently. Among other things I got an opportunity to share my thoughts about a particular phrase we hear a lot about Product Managers, one that I think is quite dangerous for our profession…

What kind of challenges and opportunities face Product Managers in a software development context?

I think the Product Management role is still incredibly misunderstood (and misused). I’ve never liked the “We’re like mini-CEOs of the Product” thing you often hear. Any metaphor you come up with that implies a hierarchy (such as air traffic controller, shepherd) gives Product Managers an incorrect view of themselves as The Boss™, and serves only to alienate teams.

We might be the final decider on some issues, but it’s not because we’re “above” the team. It’s because our jobs are to know about user needs, business goals, technical needs, and how all of it comes together in a successful product. Our jobs are to listen to our teams in their various roles and make sure that everyone knows what they need to know. And then our jobs are to walk with the team in a direction that everyone understands and agrees on. It’s not “here are your requirements, see you on the other side of design!” We still see way too much of that in the industry.

Until we change that perception, which will require a change in attitude from us as product managers, we’ll continue to be viewed as obstructionists in many companies. Maybe the best metaphor to use is that we’re servants. Servants to our customers, our teams, and the product. That’s the opportunity we have to bring value.

You can read the full interview here.

Useful daily standup meetings for remote teams

As with many distributed teams our approach to tools at Wildbit is to try to strike a balance between making sure everyone on the team knows what’s going on, and not having hours of meetings every day. We are very serious about the ability to have a lot of time during the day for focused work, so we sometimes err on the side of not enough meetings. For this reason the team hasn’t done formal daily standups for a while, instead opting for a weekly meeting to do a roundtable of what everyone’s been working on, and what the plan is for the week.

There are a couple of problems with this approach. First and foremost, it doesn’t always feel like time well spent—we shouldn’t be spending an hour a week just talking about what we’re doing. That’s why we have planning tools1. Another side effect is that it’s harder to respond quickly when issues come up. If a team member is having a problem, or we didn’t realize before that two projects are related somehow, it could take up to a week to find out what the issues are. So we wanted something better. Something lightweight, useful, and more frequent.

We realized early on that synchronous standups wouldn’t work for us—we just work across too many time zones to find a convenient time, and it also doesn’t make sense to have a standup at the end of someone’s day. We also didn’t want this to be just an update for everyone else, we wanted to make it a useful planning tool for individual work as well.

So we started looking for Standup bots built for Slack, and of course there are tons of them. We ended up signing up for Geekbot because it met our most important criterium: it’s asynchronous. We set up Geekbot to ask each team member (product, design, engineering, and QA—we’re all in this…) a set of questions at 9am in their time zone. This means each team member can use these questions to be thoughtful about their day and what they want to accomplish.

In order to make this more useful for us we also changed the questions a little bit. Usually the first question in a standup is “What did you accomplish yesterday?” This didn’t feel right to us—it felt too much like checking up on each other. Instead, we ask the question this way:

Did you work on what you wanted to yesterday? If not, what happened?

This might seems like a subtle change, but it shifts the focus quite a bit. Instead of listing out the things we did, this question allows us to tell each other if something happened that distracted us from the work we wanted to do, which helps us solve those issues as well. So here’s what our Geekbot setup looks like:

Geekbot settings

Every time someone answers these 3 questions, Geekbot posts a status in our #pm-standup team room in Slack, where we can all read through it on our own time.

There is, of course, nothing groundbreaking about what we’re doing here. But I wanted to write up our process because I know there are many distributed teams who struggle with this. The issue is always the same: How do we have standups that are useful and that don’t feel like busywork that just takes us away from the jobs we’re supposed to be doing? By using an asynchronous bot and adapting the questions to our needs, we accomplished a few important things:

  • Every member on the team takes a few minutes every morning to plan out their day, and troubleshoot anything that might have gone wrong the previous day.
  • Instead of weekly meetings of an hour long where we discuss what everyone’s working on, we now have focused 30-minute meetings every Monday where we solve problems and discuss issues that came up during the week (I keep an agenda as we progress through the week).
  • I am much more equipped to fulfill my role as Product Manager because our updates are more frequent and the signal to noise ratio is extremely high.

So even if your remote team is against the idea of a standup, I recommend you try something like this. Don’t just do what we did though. Choose your own questions, your own cadence, maybe even your own tool. But do something—start with the question “How can we make frequent checkins useful?” and see what the team comes up with.


  1. I have a whole other post planned about using Jira in small teams… 

More

  1. 1
  2. ...
  3. 62
  4. 63
  5. 64
  6. 65
  7. 66
  8. ...
  9. 202