Unfortunately, he has never talked to a single customer or an account manager (who works closely with the customers) before he came up with the design. He said that he had surveyed follow developers, and they all liked his design.

UI design is an interactive process. The best UI designers I know listen really well — they take feedback well. They treat users’ feedback as an integral part of his design process. He doesn’t take it as criticism and get offended.

Similarly, I’ve known people who does market research in their head. "I think I know my customers. They will like this." But, they have never validated their assumptions. You need to separate your own assumptions from reality. You need to talk to your customers and field sales force to validate your assumptions.

Do you know someone who is doing UI design or market research in their own head? Wake them up!

Let’s implement SCRUM! Let’s be iterative and get things out quickly! The company sent a few program managers to a scrum training course. A couple of days later, they came back with "SCRUM Master" certifications.

After a few months of scrums, very little progress were made. "It’s because we don’t have the right software tool to keep track of product backlog and scrum tasks.

The company immediately purchased Scrumwork.

A year passed. Still, the development team is as unproductive as before. The business team is as frustrated as they’ve ever been.

Ironically, the business team starts to have SCRUMS! "We need to form a cross-functional team to tackle a very complex issue. Let’s have our own SCRUM!"

Scrum is NOT the cure-all medicine. It’s a methodology. Nothing more, nothing less. Scrum alone will not make you successful.

In the 1980′s, San Francisco 49ers was the football team to beat in the national football league. Their West Coast offense was the system that many teams emulated. However, to make the West Coast offense working, a team needs a mobile quarterback (like Steve Young), a great slot receiver (like Jerry Rice), a productive tight end (like Brent Jones), and the right coach (like the "genius".) Several teams had successes emulating 49ers (e.g. Green Bay Packers under Mike Holmgreen, Oakland Raider under Jon Gruden, Philadelphia Eagles under Andy Reid.) They didn’t just put in the "west coast" methodology. They made sure that they had the right personnel, the right coach, and the right training regimen.

There are also other teams who didn’t adopt the west coast offense. The New England Patriot had huge success by having a totally different offense/defense system and personnel.

Similarly, scrum won’t work for every company and every project. It’s an effective methodology for certain projects with certain personnel at certain companies. It will not cure all of your project management problems.

Are you having a scrum mania in your organization? Please do yourself a favor — do not dive into implementing scrum without consider the strategic and organization implications of adopting scrums. It’s not that simple, and it won’t solve all of your problems!

Do you have any tips and lessons to share? Leave a comment.

I think the tension between sales and engineering are nature and healthy — they have different goals, incentives, and perspectives. But, it’s the product manager’s job to balance the immediate sales needs and product roadmap, balance short-term quick-and-dirty product enhancements and long-term project, balance flexibility and discipline.

 
As a result, sometime there is a "war" going on in my mind: I know what sales team wants and I want to help. After all, if we can not bring in enough dollars in the end of the day, we don’t have a viable business. On the other hand, I work closely with development team, and I know how constrained their resource is. Plus, I’ve been working diligently to implement a disciplined process to review and prioritize feature requests, and make sure engineering team is not randomized and distracted.

I’m going back and forth in my mind — what should I do? This is hard for me because I cannot just take a position like sales or engineering does — I have a broader perspective and understand both sides. That makes my job a lot harder!

I have used several different mental models to resolve the internalized conflict:

• "Let them battle it out" — the pure facilitator model
• "Quantify as much as we can, and let the number speak for itself" — the analytic mode
• "Presenting the facts, and product board makes the decision" — the decision deferral model

Have you find yourself in situation like this? What’s your strategy and best practices?

Tim is a product manager at a large enterprise software company in the Silicon Valley. His development team is based in India, while his business team members are in the US, UK, Germany and Japan. He has been asked to launch a major product globally.

When your job description includes "global" — it’s a blessing, but is also a curse. You need to simultaneously interact with your colleagues from multiple time zones. It’s hard.

What can you do to make yourself less stressful, more productive, and maintaining a reasonable schedule? Here is what I have learned:

• Take turns with your international teams to stay late. For example, if you stay late this time, the next time is for your international counterpart to stay late.
• Establish a good habit of writing clear, and thorough emails to answer questions.
• Don’t make yourself as the single point of contact (and failure) for all project related questions. Make sure you have some knowledge transfer to other team members in your office. They should be able to take some workload off you and help answer questions from you remote teams.
• Provided clear and detailed documentation.
• If you have development teams in both remote locations and your headquarter, carefully divide the project into "self-contained" components and components that require a lot of coordination and clarification. Give the self-contained components to your remote teams.
• If you’re going to make multiple calls at night, take some time off during the day. You need some rest and relaxation. Don’t burn yourself out — your project needs you!

Do you have any tips of working effectively with international teams and maintain life/work balance? Drop me a comment.

I got a lot of questions about my "secrets" to turn around the team and get projects done.

It’s very simple.

I set two goals for the team:
1) Set aggressive AND achievable project milestones for the project, and hit them one milestone a time.
2) Let’s work a little bit extra harder now, and nobody would pull all-nighters in the end.

In a company that was known for developer burn-out, none of my team members was working extra hours before project deadline, and all projects were delivered on time.

To achieve the two goals, I implemented a simple process:
1) to come up with aggressive yet achievable milestones, each project must be divided into small tasks that take no more than 8 hours to complete. Developer won’t give you realistic estimate unless the task is small enough.

2) identify all dependencies: Is a task dependent on some other task(s) and/or external factors? Identify them early on and continue to identify them. It’s my job as leader of the team to remove the dependencies and coordinate the tasks so that one task won’t block the other.

3) 100% transparency: weekly project status report tells exactly what’s going on with the project. No sugar coating. If anyone has any problem, let the whole team know as soon as possible. At any given time, we, as a team, must know exactly how the project is progressing against our goals and project plan.

4) have weekly "learning points" meetings, not postmortem meetings in the end of project: I don’t like postmortem meetings, which take place after a project is over. That’s too late. Let’s make project a constant learning process — each week identify what we have done right, and what mistakes we have made. Incorporate the learning to the project plan and execution immediately. Just like a basketball team, you need to have "time-out" to figure out what adjustments to make during a game. Do the same for the project.

Do these basic things. You’ll be surprised how effective they’re to get project done.