Questions? Feedback? powered by Olark live chat software

New York

Planning Software Product - The Agile Way  Tips from the Trenches  Your company (a startup, small company, or a division of a larger company) decided to build a new software product. You are in charge. What’s your first move?  Naturally (of course!), you would want to use Agile best practices to manage the process. But ask yourself — do you have enough information to begin? Where would you start? May be start with user stories?  While Agile excels at building software, such processes as companywide product planning and coordination are not directly addressed in the methodology.  As a result, “simple” questions like “How long will it take to build the product” or “What functionality will be implemented in Release 1” often answered by long explanation on how Agile works without providing specifics needed for other branches of the company. Which of course is not particularly helpful for Marketing and Sales as they prepare for product marketing campaigns and launch!  Here’s approach that worked for me in the past to ease at least some of these challenges.  The idea is to start the new product development with the lightweight Planning phase (Agile Product Planning). This phase is dedicated to achieving the following main goals:   Ensuring different parts of the company is on the same page early in the cycle in terms of the product direction and expected functionality  Formulating product vision to ensure all follow up decisions are made with this vision in mind  Outlining constraints such as business milestones and resourcing to ensure appropriate scoping and prioritization   Once the product planning is completed the regular Agile process can start with user stories breakdown, UX work, and technical design/development.   Let’s dig deeper into the Planning phase.   To make product planning more reliable it is generally a good idea to start by forming a virtual Product Planning team. The team ideally should include representatives from various departments (think Sales, Marketing, Development, and IT working together!).  Try to keep the team small — no more than 6 team members. Oh, and do not forget the Scrum Master — somebody who will coordinate the team’s planning effort.  Once the team is formed, the planning can start.  Here are the main points the Product Planning Team should address.   1. What specific problem(s) the product will solve?   Without clear and specific single sentence answer to this question you may have trouble explaining the product value to stakeholders, clients, to your own team, and to yourself!  Remember — you need to excite people about the new product, and having a good answer to this question is a great first step.   2. Who will buy the product?   A good answer to this question is extremely important for 3 reasons:   It forces the team to think beyond the technological coolness of your solution  It allows your business to start targeting future product buyers in parallel with product development.  It may affect release scope and prioritization if the product users are not the same as product buyers (something that’s quite possible in enterprise scenarios).    3. Who will use the product?   Knowing who your users are (including their roles) will help you later on with much higher quality user stories. On the business side it will drive marketing and sales targeting.  Remember that buyers and users are not always the same — it is important to understand both.   4. What are the milestones?   Often product must be completed before a well known business deadline, such as a conference where you’d like to announce it, a meeting with investors, a launch by your competitors, etc. Knowing the deadline ahead of time might influence how user stories are prioritized to ensure high quality delivery for that date.   5. Release 1 Functional Outline   Before Product team starts working on user stories, it is important to write down (and accept within Product Planning Team!) a high level Functional Outline of the first version of the product — something you can easily share with stakeholders and customers, and something that sets a common ground for the product within the company.  The outline does not need to be extensive (couple of paragraphs or several bullet points should do it). If written well, it will translate almost directly sentence-by-sentence to user stories later on.   6. Release 1 Estimate   This point is to some extent anti-Agile in nature, however in many cases it cannot be avoided in real life.  Guess what will be the first question from stakeholders once the product functionality is understood. If you guessed “When is it going to be ready” — you are right!  Unfortunately in some cases the estimate is required even before user stories are written and estimated by the development team.  To understand a magnitude of work ahead, it is generally good idea to include “Rough Order of Magnitude” estimate (ROM) in your planning cycle. ROM estimate assumes very low precision (+- 50%), but it still provides high level understanding of the product development effort: are we talking weeks, months, or years to deliver the product.  The typical practice to come up with ROM estimate:   Use Release 1 Functional Outline as a starting point.  Ask your development team how long it would take them to develop such solution. To make things interesting feel free to cap the time for this answer to 30 mins  Multiply the number developers provided by the “Team Optimism Level” (developers tend to underestimate effort 2–3 times in most cases)   The resulting number is the ROM estimate you can share with stakeholders.  Important note — ensure you make it very clear (in writing!) the estimates are preliminary and actual development may take longer or shorter depending on specifics and complexity of the requirements.   7. Beyond Release 1   Understanding what lies beyond Release 1 will help with technical decisions your team making and will reduce future refactoring. Having couple of paragraphs or several bullet points describing post-Release 1 product direction should be sufficient at this stage.  Later on it could be converted to full scale Product Roadmap!   8. Define Technology Stack   Now when developers understand the high level requirements as well as the time constraints, they can come up with a technology stack that fits the requirements and the team expertise.   9. Resourcing   Knowing the ROM estimates, deadlines, and technology stack allows to plan development resources required to deliver the product.  That’s it!  The whole process of planning may take from several hours to several days, depending on the complexity of the new product, how well the product idea is formulated, and how aligned the team members are.  It is generally good idea to use agile prioritization techniques to avoid an impasse between the Product Planning team members. See my article on  Ideas Prioritization — Agile Approach  as one of such examples.  Smooth Agile development process from this point on!   Written by Alex Apollonsky CTO at  OysterLabs    Originally Published on  Medium.com

Planning Software Product - The Agile Way
Tips from the Trenches

Your company (a startup, small company, or a division of a larger company) decided to build a new software product. You are in charge. What’s your first move?

Naturally (of course!), you would want to use Agile best practices to manage the process. But ask yourself — do you have enough information to begin? Where would you start? May be start with user stories?

While Agile excels at building software, such processes as companywide product planning and coordination are not directly addressed in the methodology.

As a result, “simple” questions like “How long will it take to build the product” or “What functionality will be implemented in Release 1” often answered by long explanation on how Agile works without providing specifics needed for other branches of the company. Which of course is not particularly helpful for Marketing and Sales as they prepare for product marketing campaigns and launch!

Here’s approach that worked for me in the past to ease at least some of these challenges.

The idea is to start the new product development with the lightweight Planning phase (Agile Product Planning). This phase is dedicated to achieving the following main goals:

  • Ensuring different parts of the company is on the same page early in the cycle in terms of the product direction and expected functionality
  • Formulating product vision to ensure all follow up decisions are made with this vision in mind
  • Outlining constraints such as business milestones and resourcing to ensure appropriate scoping and prioritization

Once the product planning is completed the regular Agile process can start with user stories breakdown, UX work, and technical design/development.

Let’s dig deeper into the Planning phase.

To make product planning more reliable it is generally a good idea to start by forming a virtual Product Planning team. The team ideally should include representatives from various departments (think Sales, Marketing, Development, and IT working together!).

Try to keep the team small — no more than 6 team members. Oh, and do not forget the Scrum Master — somebody who will coordinate the team’s planning effort.

Once the team is formed, the planning can start.

Here are the main points the Product Planning Team should address.

1. What specific problem(s) the product will solve?

Without clear and specific single sentence answer to this question you may have trouble explaining the product value to stakeholders, clients, to your own team, and to yourself!

Remember — you need to excite people about the new product, and having a good answer to this question is a great first step.

2. Who will buy the product?

A good answer to this question is extremely important for 3 reasons:

  • It forces the team to think beyond the technological coolness of your solution
  • It allows your business to start targeting future product buyers in parallel with product development.
  • It may affect release scope and prioritization if the product users are not the same as product buyers (something that’s quite possible in enterprise scenarios).

3. Who will use the product?

Knowing who your users are (including their roles) will help you later on with much higher quality user stories. On the business side it will drive marketing and sales targeting.

Remember that buyers and users are not always the same — it is important to understand both.

4. What are the milestones?

Often product must be completed before a well known business deadline, such as a conference where you’d like to announce it, a meeting with investors, a launch by your competitors, etc. Knowing the deadline ahead of time might influence how user stories are prioritized to ensure high quality delivery for that date.

5. Release 1 Functional Outline

Before Product team starts working on user stories, it is important to write down (and accept within Product Planning Team!) a high level Functional Outline of the first version of the product — something you can easily share with stakeholders and customers, and something that sets a common ground for the product within the company.

The outline does not need to be extensive (couple of paragraphs or several bullet points should do it). If written well, it will translate almost directly sentence-by-sentence to user stories later on.

6. Release 1 Estimate

This point is to some extent anti-Agile in nature, however in many cases it cannot be avoided in real life.

Guess what will be the first question from stakeholders once the product functionality is understood. If you guessed “When is it going to be ready” — you are right!

Unfortunately in some cases the estimate is required even before user stories are written and estimated by the development team.

To understand a magnitude of work ahead, it is generally good idea to include “Rough Order of Magnitude” estimate (ROM) in your planning cycle. ROM estimate assumes very low precision (+- 50%), but it still provides high level understanding of the product development effort: are we talking weeks, months, or years to deliver the product.

The typical practice to come up with ROM estimate:

  • Use Release 1 Functional Outline as a starting point.
  • Ask your development team how long it would take them to develop such solution. To make things interesting feel free to cap the time for this answer to 30 mins
  • Multiply the number developers provided by the “Team Optimism Level” (developers tend to underestimate effort 2–3 times in most cases)

The resulting number is the ROM estimate you can share with stakeholders.

Important note — ensure you make it very clear (in writing!) the estimates are preliminary and actual development may take longer or shorter depending on specifics and complexity of the requirements.

7. Beyond Release 1

Understanding what lies beyond Release 1 will help with technical decisions your team making and will reduce future refactoring. Having couple of paragraphs or several bullet points describing post-Release 1 product direction should be sufficient at this stage.

Later on it could be converted to full scale Product Roadmap!

8. Define Technology Stack

Now when developers understand the high level requirements as well as the time constraints, they can come up with a technology stack that fits the requirements and the team expertise.

9. Resourcing

Knowing the ROM estimates, deadlines, and technology stack allows to plan development resources required to deliver the product.

That’s it!

The whole process of planning may take from several hours to several days, depending on the complexity of the new product, how well the product idea is formulated, and how aligned the team members are.

It is generally good idea to use agile prioritization techniques to avoid an impasse between the Product Planning team members. See my article on Ideas Prioritization — Agile Approach as one of such examples.

Smooth Agile development process from this point on!

Written by Alex Apollonsky CTO at OysterLabs

Originally Published on Medium.com

Join us in designing the future of mobile products and platforms! Headquartered in New York City, we’re a passionate team working closely with exciting startups and brands to deliver strategic mobile offerings.   
  Interested?  Email us at   careers@oysterlabs.com   
   OysterLabs   is seeking a skilled Mobile UX Designer to work with clients and internal teams to meet the demands of our growing client base.  Must have mobile app design experience and have a deep understanding of UX design.  The ideal candidate will be comfortable working in a fast-paced environment and have a basic understanding of Agile / Scrum methodology. 
 Mobile Designers at OysterLabs will work directly with our Creative Director to create modern, polished experiences for our clients.  
  RESPONSIBILITIES   
  Work directly with Creative Director and clients to ideate and define design vision and design mobile app interfaces.  
 Help define the core product vision, goals, functionality and requirements. 
 Collaborate with engineers to reach the best possible version of a feature or product to bring to market. 
 Create use cases that deliver on the user experience. 
 Prioritize development activities with engineering teams to deliver iterative design. 
   QUALIFICATIONS  
  Minimum 2 years of mobile app design experience. 
 Understanding of the latest iOS and Android design requirements. 
 Experience with agile methodologies. 
 Proven track record of leading and delivering design of mobile products. 
 Strong leadership, communication and presentation skills. 
 Comfortable working direct with clients and understand additional business opportunities.  
 Experience using JIRA or similar project management software. 
 Strong analytical problem solving and decision making skills. 
 Demonstrated thoroughness, follow-up and attention to detail. 
 BA/BS Degree. 
   When submitting your resume, please include link to your portfolio.  
  OysterLabs is an equal opportunity employer (EOE).  
  ABOUT  
 OysterLabs is a mobile technology company. We create special mobile app experiences for our customers and have just launched a proprietary SaaS based Analytics, CRM and Messaging platform for mobile apps, called OysterLabs AQUA™. We define the way brands and companies build valuable relationships with their mobile audience as well as understand the data that can dictate future mobile strategy and iterations of development. 
  Interested?  Email us at   careers@oysterlabs.com

Join us in designing the future of mobile products and platforms! Headquartered in New York City, we’re a passionate team working closely with exciting startups and brands to deliver strategic mobile offerings. 

Interested? Email us at careers@oysterlabs.com

OysterLabs is seeking a skilled Mobile UX Designer to work with clients and internal teams to meet the demands of our growing client base.  Must have mobile app design experience and have a deep understanding of UX design.  The ideal candidate will be comfortable working in a fast-paced environment and have a basic understanding of Agile / Scrum methodology.

Mobile Designers at OysterLabs will work directly with our Creative Director to create modern, polished experiences for our clients. 

RESPONSIBILITIES 

  • Work directly with Creative Director and clients to ideate and define design vision and design mobile app interfaces. 
  • Help define the core product vision, goals, functionality and requirements.
  • Collaborate with engineers to reach the best possible version of a feature or product to bring to market.
  • Create use cases that deliver on the user experience.
  • Prioritize development activities with engineering teams to deliver iterative design.

QUALIFICATIONS

  • Minimum 2 years of mobile app design experience.
  • Understanding of the latest iOS and Android design requirements.
  • Experience with agile methodologies.
  • Proven track record of leading and delivering design of mobile products.
  • Strong leadership, communication and presentation skills.
  • Comfortable working direct with clients and understand additional business opportunities. 
  • Experience using JIRA or similar project management software.
  • Strong analytical problem solving and decision making skills.
  • Demonstrated thoroughness, follow-up and attention to detail.
  • BA/BS Degree.

When submitting your resume, please include link to your portfolio.

OysterLabs is an equal opportunity employer (EOE).

ABOUT

OysterLabs is a mobile technology company. We create special mobile app experiences for our customers and have just launched a proprietary SaaS based Analytics, CRM and Messaging platform for mobile apps, called OysterLabs AQUA™. We define the way brands and companies build valuable relationships with their mobile audience as well as understand the data that can dictate future mobile strategy and iterations of development.

Interested? Email us at careers@oysterlabs.com

Mobile and the NBA    
 Something’s brewing in the NBA between Sacramento Kings owner, Vivek Ranadive, and Dallas Mavericks’ owner, Mark Cuban. No, it’s not about King James and the MVP Race or David Stern’s retirement. Believe it or not, they’re bickering about the use of mobile technology during live NBA games. 
 Ranadive, who purchased the Kings in May 2013, believes that mobile will  enhance the experience  of being in an arena during a live NBA game. He noted,  
 
  “The future is about giving people an extremely contextual experience…people love to play games and they love to participate.”   
 
   
 Ranadive believes an in-game app, like the one at the  Barclays Center  in Brooklyn, enhances the experience, rather than disrupts it. The Barclays Center’s new mobile Wi-Fi system allows fans to access game information, with future versions including the ability to order concessions from your phone. Ranadive said, 
 
  “I completely reject the notion that a fan looking at his mobile device is not an engaged fan…I want to know play-by-play, I want to know every metric.”  
 
 On the other side of this debate is longtime Mavericks owner, Mark Cuban. Cuban wants nothing more than to see fans put their phones away and become immersed in the game. Cuban said, 
 
  “No question people use their phones and devices at games…but they use them when they are bored. They don’t want more reasons to use them. They want fewer.”      
 
  A new study on stadium Wi-Fi habits , commissioned by the NFL, discovered that the busiest period of mobile use during a game comes at the beginning and mobile use slowly decreases during the game.  Most of that mobile activity is not looking at the play-by-play or statistics; rather, it’s photo uploading through Facebook.  Maybe Cuban is right. But then again, mobile apps catered to the in-game experience are not widely available yet and the lack of in-game use may be due to a lack of availability. 
 I do know that when I’m at home, watching the game, I’m using multiple devices at the same time. But, when I’m at a live NBA game, I rarely take my phone out. Why would I? I just paid a ridiculous price for a ticket. 
  Final Thoughts  In reality, both owners are right. NBA fans are a diverse group of people. Some would love the extra features of being able to look up stats and figures related to the game. Others would find it distracting, and would prefer to keep the phone in their pocket. The real key here is giving those fans who prefer the mobile experience, a great app that meets their needs. Cuban needs to step into the 21 st  century and reach out to Mavericks fans that fall into this group.  
 Regardless, I’m a Knicks fan; so I’d rather not look at the game anyway…

Mobile and the NBA 

Something’s brewing in the NBA between Sacramento Kings owner, Vivek Ranadive, and Dallas Mavericks’ owner, Mark Cuban. No, it’s not about King James and the MVP Race or David Stern’s retirement. Believe it or not, they’re bickering about the use of mobile technology during live NBA games.

Ranadive, who purchased the Kings in May 2013, believes that mobile will enhance the experience of being in an arena during a live NBA game. He noted,

“The future is about giving people an extremely contextual experience…people love to play games and they love to participate.”

Ranadive believes an in-game app, like the one at the Barclays Center in Brooklyn, enhances the experience, rather than disrupts it. The Barclays Center’s new mobile Wi-Fi system allows fans to access game information, with future versions including the ability to order concessions from your phone. Ranadive said,

“I completely reject the notion that a fan looking at his mobile device is not an engaged fan…I want to know play-by-play, I want to know every metric.”

On the other side of this debate is longtime Mavericks owner, Mark Cuban. Cuban wants nothing more than to see fans put their phones away and become immersed in the game. Cuban said,

“No question people use their phones and devices at games…but they use them when they are bored. They don’t want more reasons to use them. They want fewer.”  

A new study on stadium Wi-Fi habits, commissioned by the NFL, discovered that the busiest period of mobile use during a game comes at the beginning and mobile use slowly decreases during the game.  Most of that mobile activity is not looking at the play-by-play or statistics; rather, it’s photo uploading through Facebook.  Maybe Cuban is right. But then again, mobile apps catered to the in-game experience are not widely available yet and the lack of in-game use may be due to a lack of availability.

I do know that when I’m at home, watching the game, I’m using multiple devices at the same time. But, when I’m at a live NBA game, I rarely take my phone out. Why would I? I just paid a ridiculous price for a ticket.

Final Thoughts
In reality, both owners are right. NBA fans are a diverse group of people. Some would love the extra features of being able to look up stats and figures related to the game. Others would find it distracting, and would prefer to keep the phone in their pocket. The real key here is giving those fans who prefer the mobile experience, a great app that meets their needs. Cuban needs to step into the 21st century and reach out to Mavericks fans that fall into this group. 

Regardless, I’m a Knicks fan; so I’d rather not look at the game anyway…